From pje at telecommunity.com  Sat Sep  3 07:06:45 2005
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sat, 03 Sep 2005 01:06:45 -0400
Subject: [Catalog-sig] [Distutils] setuptools 0.6a1 candidate 2 snapshot
In-Reply-To: <5.1.1.6.0.20050821235458.01afafd8@mail.telecommunity.com>
Message-ID: <5.1.1.6.0.20050903010319.01b89080@mail.telecommunity.com>

There were bug reports about bdist_rpm, and some issues installing on SuSE 
Linux, which has a patched version of distutils for no particular reason 
(that Google knows about, anyway).  In the process of fixing these, I found 
some other problems and went ahead and fixed those too.  So, there's now an 
0.6a1c2 snapshot you can use, via the instructions below.  Please let me 
know about any problems; if everything looks good, we'll go to 0.6a1 
sometime next week.

At 12:03 AM 8/22/2005 -0400, Phillip J. Eby wrote:
>This thing's been in limbo too long, so I've made a prerelease
>snapshot.  You can get it with:
>
>      easy_install -f http://peak.telecommunity.com/snapshots/ setuptools
>
>I have fixed all reported bugs, and implemented quite a few new features
>like MD5 checking (which works even with PyPI's md5 data) and an enhanced
>"build_ext --inplace" that lets you switch between different Python
>interpreters without having to recompile your extensions.  (The extensions
>are built in build/, then copied to the source tree whenever you
>"build_ext" using a different interpreter than the last.)
>
>If you have any projects using setuptools, I encourage you to give this
>snapshot a try, so I can find out if there are still any lurking bugs.  If
>there are no bug reports by next weekend, this will get pushed out as 0.6a1.
>If you want to look at the documentation, use CVS or browse the
>EasyInstall.txt, setuptools.txt, and pkg_resources.txt files found at:
>
> 
>http://cvs.sourceforge.net/viewcvs.py/python/python/nondist/sandbox/setuptools/
>
>(I just made some changes to these, however, that may take a few hours to
>update in SourceForge's anonymous CVS.)


From pje at telecommunity.com  Wed Sep 14 08:08:05 2005
From: pje at telecommunity.com (Phillip J. Eby)
Date: Wed, 14 Sep 2005 02:08:05 -0400
Subject: [Catalog-sig] setuptools 0.6a1 is officially released
Message-ID: <5.1.1.6.0.20050914020751.03260c58@mail.telecommunity.com>

and is available from PyPI.  The latest bootstrap script is at:

     http://peak.telecommunity.com/dist/ez_setup.py

And updated HTML documentation is available at:

    http://peak.telecommunity.com/DevCenter/setuptools  (developers/deployers)
    http://peak.telecommunity.com/DevCenter/EasyInstall (administrators/users)
    http://peak.telecommunity.com/DevCenter/PkgResources (runtime reference)

There are way too many new features to list coherently, but some highlights 
include better support for non-root installs, RPM support, performance 
enhancements, a new "entry point" system for linking plugins to extensible 
apps and frameworks, a lot more documentation, and more than a few bug fixes.

Please send questions, comments, and bug reports to distutils-sig at python.org. 


From mauriceling at acm.org  Fri Sep 16 16:46:40 2005
From: mauriceling at acm.org (Maurice Ling)
Date: Sat, 17 Sep 2005 00:46:40 +1000
Subject: [Catalog-sig] centipyde - a simple installation manager
Message-ID: <432ADAD0.2010809@acm.org>

Hi all,

A few months back, I was rattering about the pains of having to upgrade 
to a new version of Python and thereby having 2 site-packages directory, 
and having to re-install every needed package again.

Well, it happened to me today. Fink installed Python 2.4.0 as part of 
the updating process and I'm in the process of re-installing many of my 
packages.

As mentioned few months back, I am putting a small part of my time to 
work on a Fink/Darwinport-like package manager for Python. So far I've 
came up with something but please pardon me... it is still very infant 
and very raw. It can be obtained from SF's CVS:

cvs -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/ib-dwb login
 
cvs -z3 -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/ib-dwb co -P 
/centipyde/

Currently there are 3 packages to be installed: PLY 1.5, PLY 1.6, and kinterbasdb 3.1.2

So command to install is "sudo python centipyde.py install {ply15|ply16|kinterbasdb312}" in centipyde directory. 

I've basically categorize the installation into several types,
1: no dependencies, and only require 1 time of 'python setup.py build; sudo python setup.py install'. Originally meant for pure python packages. (this is the one and only one available now)

2: ... haven't really thought of it ... but should be in the area of dependencies handling, where each node in the dependency tree require only type 1/2 installation.

Please give me your opinions.

Cheers
Maurice

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mauriceling.vcf
Type: text/x-vcard
Size: 324 bytes
Desc: not available
Url : http://mail.python.org/pipermail/catalog-sig/attachments/20050917/51fc92fe/mauriceling.vcf

From ianb at colorstudy.com  Wed Sep 21 03:19:42 2005
From: ianb at colorstudy.com (Ian Bicking)
Date: Tue, 20 Sep 2005 20:19:42 -0500
Subject: [Catalog-sig] setuptools: name quoting
In-Reply-To: <5.1.1.6.0.20050920210448.0348dd00@mail.telecommunity.com>
References: <5.1.1.6.0.20050920210448.0348dd00@mail.telecommunity.com>
Message-ID: <4330B52E.3090802@colorstudy.com>

Phillip J. Eby wrote:
> At 02:59 PM 9/20/2005 -0500, Ian Bicking wrote:
> 
>> I'm a bit confused about name quoting.  I have a package with a name
>> "Todo_SQLObject_ZPT", and egg_info writes to
>> "Todo-SQLObject-ZPT.egg-info".  Why?  I thought -'s were bad, but _'s
>> were okay...?
> 
> 
> It's safe to use either, but setuptools considers '-' to be canonical;
> this was a heuristic decision on my part because '-' appears more
> frequently used than '_' in the names of projects currently registered
> with PyPI.
> 
> The problem, however, is that PyPI wants your uploaded files to
> *exactly* match the registered name.  If you used '-' in setup.py, you
> must have '-' in the filename, and that's something setuptools cannot
> do.  It would probably be best if setuptools ensured the "register"
> command always used '_', but then this defeats the purpose of having it
> that way in the first place!
> 
> So, the only real fix is to change PyPI to accept files whose
> pkg_resources.safe_name() match the safe_name() of the project.  In the
> meantime, you can't upload eggs to PyPI for packages with '-' or '_' in
> their names.  (You can upload source distros or other formats, since
> those can work with ambiguous filenames.) I probably should put in an
> RFE or proposed patch, but I've been *really* busy lately.

Richard, would you be able to make this change?  It seems pretty
reasonable to accept files that closely match project names.


From pje at telecommunity.com  Wed Sep 21 03:31:24 2005
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 20 Sep 2005 21:31:24 -0400
Subject: [Catalog-sig] setuptools: name quoting
In-Reply-To: <4330B52E.3090802@colorstudy.com>
References: <5.1.1.6.0.20050920210448.0348dd00@mail.telecommunity.com>
	<5.1.1.6.0.20050920210448.0348dd00@mail.telecommunity.com>
Message-ID: <5.1.1.6.0.20050920212443.020ce820@mail.telecommunity.com>

At 08:19 PM 9/20/2005 -0500, Ian Bicking wrote:
>Phillip J. Eby wrote:
> > At 02:59 PM 9/20/2005 -0500, Ian Bicking wrote:
> >
> >> I'm a bit confused about name quoting.  I have a package with a name
> >> "Todo_SQLObject_ZPT", and egg_info writes to
> >> "Todo-SQLObject-ZPT.egg-info".  Why?  I thought -'s were bad, but _'s
> >> were okay...?
> >
> >
> > It's safe to use either, but setuptools considers '-' to be canonical;
> > this was a heuristic decision on my part because '-' appears more
> > frequently used than '_' in the names of projects currently registered
> > with PyPI.
> >
> > The problem, however, is that PyPI wants your uploaded files to
> > *exactly* match the registered name.  If you used '-' in setup.py, you
> > must have '-' in the filename, and that's something setuptools cannot
> > do.  It would probably be best if setuptools ensured the "register"
> > command always used '_', but then this defeats the purpose of having it
> > that way in the first place!
> >
> > So, the only real fix is to change PyPI to accept files whose
> > pkg_resources.safe_name() match the safe_name() of the project.  In the
> > meantime, you can't upload eggs to PyPI for packages with '-' or '_' in
> > their names.  (You can upload source distros or other formats, since
> > those can work with ambiguous filenames.) I probably should put in an
> > RFE or proposed patch, but I've been *really* busy lately.
>
>Richard, would you be able to make this change?  It seems pretty
>reasonable to accept files that closely match project names.

FYI, here are the safe_name/safe_version source:

def safe_name(name):
     """Convert an arbitrary string to a standard distribution name

     Any runs of non-alphanumeric characters are replaced with a single '-'.
     """
     return re.sub('[^A-Za-z0-9]+', '-', name)


def safe_version(version):
     """Convert an arbitrary string to a standard version string

     Spaces become dots, and all other non-alphanumeric characters become
     dashes, with runs of multiple dashes condensed to a single dash.
     """
     version = version.replace(' ','.')
     return re.sub('[^A-Za-z0-9.]+', '-', version)

To make an egg filename, these strings are taken and the '-' converted to a 
'_' so that it isn't confused with the '-' that goes between parts of the 
name.  So given the metadata:

     setup(
         name="To-Do List",
         version="1.23 alpha!",
         ...
     )

The egg filename will be "To_Do_List-1.23.alpha_-py2.4-win32.egg" if 
generated by Python 2.4 on Windows (and it contains C 
extensions).  Currently, if I understand it correctly, PyPI will reject 
this name if the name and version used for registration were "To-Do List" 
and "1.23 alpha!".


From richardjones at optushome.com.au  Wed Sep 21 05:46:57 2005
From: richardjones at optushome.com.au (Richard Jones)
Date: Wed, 21 Sep 2005 13:46:57 +1000
Subject: [Catalog-sig] setuptools: name quoting
In-Reply-To: <4330B52E.3090802@colorstudy.com>
References: <5.1.1.6.0.20050920210448.0348dd00@mail.telecommunity.com>
	<4330B52E.3090802@colorstudy.com>
Message-ID: <200509211347.02242.richardjones@optushome.com.au>

On Wed, 21 Sep 2005 11:19 am, Ian Bicking wrote:
> Richard, would you be able to make this change?  It seems pretty
> reasonable to accept files that closely match project names.

Yes, as long as there's no chance of conflicts between project names due to 
the rewriting, which I figure is pretty remote given we're not touching 
alphanums.

As for when I would actually be able to make this change. Well, I'll look into 
it as soon as I can, but at the moment my plate is pretty full :(


     Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.python.org/pipermail/catalog-sig/attachments/20050921/ccc5ea18/attachment.pgp

From ianb at colorstudy.com  Wed Sep 21 09:57:14 2005
From: ianb at colorstudy.com (Ian Bicking)
Date: Wed, 21 Sep 2005 02:57:14 -0500
Subject: [Catalog-sig] Cheese Shop: download count
Message-ID: <4331125A.6080003@colorstudy.com>

Is the "number of downloads" broken on PyPI?  I just checked a project:
http://www.python.org/pypi/SQLObject/0.7b1 -- and I know it had
downloads (myself for one ;)


From fdrake at gmail.com  Wed Sep 21 16:38:36 2005
From: fdrake at gmail.com (Fred Drake)
Date: Wed, 21 Sep 2005 10:38:36 -0400
Subject: [Catalog-sig] Hide? Yes/No field on package edit page
Message-ID: <9cee7ab8050921073878e3a6f0@mail.gmail.com>

At some point, Andrew Kuchling sent a request for help regarding the
ZPT code for the Hide? Yes/No field in the table on the package
editing page.  I'd be replying to that, but I've managed to lose the
email.

Anyway, I checked in a change to the pypi templates on SourceForge
last night to fix that; someone who can update the live installation
probably wants to pick that up from pypi/templates/pkg_edit.pt in the
SourceForge CVS.

(Is that still the right place to make changes?  I vaguely recall
something about moving it to svn.python.org, but only now after I've
made the change on SF.)


  -Fred

--
Fred L. Drake, Jr.    <fdrake at gmail.com>
Zope Corporation

From richardjones at optushome.com.au  Thu Sep 22 11:48:08 2005
From: richardjones at optushome.com.au (Richard Jones)
Date: Thu, 22 Sep 2005 19:48:08 +1000
Subject: [Catalog-sig] Hide? Yes/No field on package edit page
In-Reply-To: <9cee7ab8050921073878e3a6f0@mail.gmail.com>
References: <9cee7ab8050921073878e3a6f0@mail.gmail.com>
Message-ID: <200509221948.12884.richardjones@optushome.com.au>

On Thu, 22 Sep 2005 12:38 am, Fred Drake wrote:
> Anyway, I checked in a change to the pypi templates on SourceForge
> last night to fix that; someone who can update the live installation
> probably wants to pick that up from pypi/templates/pkg_edit.pt in the
> SourceForge CVS.

Do you have a diff?


> (Is that still the right place to make changes?  I vaguely recall
> something about moving it to svn.python.org, but only now after I've
> made the change on SF.)

The code on sourceforge is out of date. Hurm. I forgot to ask them to remove 
the project :(


     Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.python.org/pipermail/catalog-sig/attachments/20050922/639ea2d1/attachment.pgp

From richardjones at optushome.com.au  Thu Sep 22 11:50:33 2005
From: richardjones at optushome.com.au (Richard Jones)
Date: Thu, 22 Sep 2005 19:50:33 +1000
Subject: [Catalog-sig] Cheese Shop: download count
In-Reply-To: <4331125A.6080003@colorstudy.com>
References: <4331125A.6080003@colorstudy.com>
Message-ID: <200509221950.34219.richardjones@optushome.com.au>

On Wed, 21 Sep 2005 05:57 pm, Ian Bicking wrote:
> Is the "number of downloads" broken on PyPI?  I just checked a project:
> http://www.python.org/pypi/SQLObject/0.7b1 -- and I know it had
> downloads (myself for one ;)

The count is updated by a cron job. If it's run. Which I don't know. I've 
cc'ed AMK to see whether he knows anything about it :)


    Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.python.org/pipermail/catalog-sig/attachments/20050922/45f5c7da/attachment.pgp

From fdrake at gmail.com  Thu Sep 22 15:36:35 2005
From: fdrake at gmail.com (Fred Drake)
Date: Thu, 22 Sep 2005 09:36:35 -0400
Subject: [Catalog-sig] Hide? Yes/No field on package edit page
In-Reply-To: <200509221948.12884.richardjones@optushome.com.au>
References: <9cee7ab8050921073878e3a6f0@mail.gmail.com>
	<200509221948.12884.richardjones@optushome.com.au>
Message-ID: <9cee7ab8050922063621331c8c@mail.gmail.com>

On 9/22/05, Richard Jones <richardjones at optushome.com.au> wrote:
> Do you have a diff?

Attached.

> The code on sourceforge is out of date. Hurm. I forgot to ask them to remove
> the project :(

Ugh.


  -Fred

--
Fred L. Drake, Jr.    <fdrake at gmail.com>
Zope Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hide-yes-no.patch
Type: text/x-patch
Size: 1098 bytes
Desc: not available
Url : http://mail.python.org/pipermail/catalog-sig/attachments/20050922/72966c26/hide-yes-no.bin

From richardjones at optushome.com.au  Fri Sep 23 02:25:51 2005
From: richardjones at optushome.com.au (Richard Jones)
Date: Fri, 23 Sep 2005 10:25:51 +1000
Subject: [Catalog-sig] setuptools or PyPI problem...?
In-Reply-To: <430A18D3.5040700@colorstudy.com>
References: <430A18D3.5040700@colorstudy.com>
Message-ID: <200509231025.52017.richardjones@optushome.com.au>

On Tue, 23 Aug 2005 04:26 am, Ian Bicking wrote:
> I don't know which side this belongs to, but I had a problem when I
> tried to create a package with a "-" in it ("Paste-Deploy").  setup.py
> register worked fine, and created a "Paste-Deploy" project; however,
> when I did an upload it created a "Paste_Deploy-0.1.tar.gz" file, and
> PyPI wouldn't accept it, I believe because it thought it belonged to the
> (nonexistant) Paste_Deploy project.

The only restrictions PyPI places on filenames for uploads are:

        # check for valid filenames
        filename = content.filename
        if not safe_filenames.match(filename):
            raise FormError, 'invalid distribution file'

        # check for dodgy filenames
        if '/' in filename or '\\' in filename:
            raise FormError, 'invalid distribution file'

        # check the file for valid contents based on the type
        if not verify_filetype.is_distutils_file(content, filename, filetype):
            raise FormError, 'invalid distribution file'

Where:

  safe_filenames = re.compile(r'.+?\.(exe|tar\.gz|bz2|rpm|deb|zip|tgz|egg)$',
      re.I)

and "is_distutils_file" just looks at the extension and pokes into the file 
based on the extension to make sure that an ".exe" uplood looks kinda like an 
installer, and ".zip" and ".egg" uploads look kinda like ZIP files of 
distutils origin.

No checks are made that a filename matches a package name. So given the 
metadata:

     setup(
         name="To-Do List",
         version="1.23 alpha!",
         ...
     )

as long as that *name* (and version) is passed unchanged to PyPI, a file named 
"frozzleplop-1.2.3.zip" could be attached to the "To-Do List" package.

I can only assume that setuptools is mutating the name/version in order to 
generate a safe filename, but then passing the mutated name/version to PyPI 
as the release identifier. I think it's an unacceptable change to make to 
PyPI to accept the mutated name/version, as the name/version represents the 
unique identifier in the database for a package. Unique identifier collisions 
are possible when you start mangling them, and I'd really prefer to avoid 
such things.


     Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.python.org/pipermail/catalog-sig/attachments/20050923/7f0886cb/attachment.pgp

From westside_indie at yahoo.com  Fri Sep 23 03:40:43 2005
From: westside_indie at yahoo.com (John Walton)
Date: Thu, 22 Sep 2005 18:40:43 -0700 (PDT)
Subject: [Catalog-sig] Network/Internet Terms I should probably know
Message-ID: <20050923014044.11969.qmail@web31003.mail.mud.yahoo.com>

Hello, again.  I'm back with my instant messenger
project.  My teacher has assigned us to write our
papers, excluding the procedure, results, and
conclusion.  One of my topics is going to be networks.
 Does anyone know a list of words relating to
networking/networks that I should know for this
project?  Not the definitions, but just the words; I
can look up the definitions on webopedia.  It would be
appreciated.  Thanks!
-John

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

From pje at telecommunity.com  Fri Sep 23 05:32:17 2005
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu, 22 Sep 2005 23:32:17 -0400
Subject: [Catalog-sig] [Distutils]  setuptools or PyPI problem...?
In-Reply-To: <200509231025.52017.richardjones@optushome.com.au>
References: <430A18D3.5040700@colorstudy.com> <430A18D3.5040700@colorstudy.com>
Message-ID: <5.1.1.6.0.20050922232636.01b5fc40@mail.telecommunity.com>

At 10:25 AM 9/23/2005 +1000, Richard Jones wrote:
>I can only assume that setuptools is mutating the name/version in order to
>generate a safe filename, but then passing the mutated name/version to PyPI
>as the release identifier.

I haven't attempted to reproduce Ian's problem, but I don't believe I'm 
doing this, at least not in the upload command.  I'll have to check.


>  I think it's an unacceptable change to make to
>PyPI to accept the mutated name/version, as the name/version represents the
>unique identifier in the database for a package. Unique identifier collisions
>are possible when you start mangling them, and I'd really prefer to avoid
>such things.

I'd like to encourage moving towards mangling the *keys* themselves, in 
order to be robust in the face of typos.  I think allowing random 
punctuation and upper/lower case to distinguish projects (e.g. allowing 
SQLObject, sqlobject, and SQLobject to be different packages) is asking for 
trouble on the human side of things, entirely aside from allowing them in 
filenames, dealing with case-insensitive filesystems, and so on.  Having a 
nice human readable name for the web page, PKG-INFO, and description are 
one thing, but having it used for filenames, URLs, and database keys is 
quite another.


From richardjones at optushome.com.au  Fri Sep 23 05:37:43 2005
From: richardjones at optushome.com.au (Richard Jones)
Date: Fri, 23 Sep 2005 13:37:43 +1000
Subject: [Catalog-sig] [Distutils]  setuptools or PyPI problem...?
In-Reply-To: <5.1.1.6.0.20050922232636.01b5fc40@mail.telecommunity.com>
References: <430A18D3.5040700@colorstudy.com>
	<5.1.1.6.0.20050922232636.01b5fc40@mail.telecommunity.com>
Message-ID: <200509231337.46971.richardjones@optushome.com.au>

On Fri, 23 Sep 2005 01:32 pm, Phillip J. Eby wrote:
> I'd like to encourage moving towards mangling the *keys* themselves, in
> order to be robust in the face of typos. ?I think allowing random
> punctuation and upper/lower case to distinguish projects (e.g. allowing
> SQLObject, sqlobject, and SQLobject to be different packages) is asking for
> trouble on the human side of things, entirely aside from allowing them in
> filenames, dealing with case-insensitive filesystems, and so on. ?Having a
> nice human readable name for the web page, PKG-INFO, and description are
> one thing, but having it used for filenames, URLs, and database keys is
> quite another.

I believe what you're proposing would require changing Python itself so it 
enforces restrictions on package names (ie. all lower-case, very limited 
punctuation, no whitespace). I think that's a good idea, but I also think at 
this point that the cat's out of the bag :(

Happy to hear contradictory views and be shouted down.


     Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.python.org/pipermail/catalog-sig/attachments/20050923/88f99793/attachment.pgp

From richardjones at optushome.com.au  Fri Sep 23 05:42:24 2005
From: richardjones at optushome.com.au (Richard Jones)
Date: Fri, 23 Sep 2005 13:42:24 +1000
Subject: [Catalog-sig] [Distutils]  setuptools or PyPI problem...?
In-Reply-To: <5.1.1.6.0.20050922232636.01b5fc40@mail.telecommunity.com>
References: <430A18D3.5040700@colorstudy.com>
	<5.1.1.6.0.20050922232636.01b5fc40@mail.telecommunity.com>
Message-ID: <200509231342.25140.richardjones@optushome.com.au>

On Fri, 23 Sep 2005 01:32 pm, you wrote:
> At 10:25 AM 9/23/2005 +1000, Richard Jones wrote:
> >I can only assume that setuptools is mutating the name/version in order to
> >generate a safe filename, but then passing the mutated name/version to
> > PyPI as the release identifier.
>
> I haven't attempted to reproduce Ian's problem, but I don't believe I'm
> doing this, at least not in the upload command.  I'll have to check.

Oh, I just changed the distutils upload command a little so that it could 
auto-register a release if someone tries to upload a file for a release 
they've not "setup.py registered"'ed yet.

It's submitted to the python sf.net tracker, but sf.net's being flaky at the 
moment so I don't have a direct URL.


    Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: upload.py-patch
Type: text/x-diff
Size: 2103 bytes
Desc: not available
Url : http://mail.python.org/pipermail/catalog-sig/attachments/20050923/2a8139d7/upload.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.python.org/pipermail/catalog-sig/attachments/20050923/2a8139d7/attachment.pgp

From pje at telecommunity.com  Fri Sep 23 17:40:57 2005
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 23 Sep 2005 11:40:57 -0400
Subject: [Catalog-sig] [Distutils]  setuptools or PyPI problem...?
In-Reply-To: <200509231337.46971.richardjones@optushome.com.au>
References: <5.1.1.6.0.20050922232636.01b5fc40@mail.telecommunity.com>
	<430A18D3.5040700@colorstudy.com>
	<5.1.1.6.0.20050922232636.01b5fc40@mail.telecommunity.com>
Message-ID: <5.1.1.6.0.20050923113747.01b77950@mail.telecommunity.com>

At 01:37 PM 9/23/2005 +1000, Richard Jones wrote:
>On Fri, 23 Sep 2005 01:32 pm, Phillip J. Eby wrote:
> > I'd like to encourage moving towards mangling the *keys* themselves, in
> > order to be robust in the face of typos.  I think allowing random
> > punctuation and upper/lower case to distinguish projects (e.g. allowing
> > SQLObject, sqlobject, and SQLobject to be different packages) is asking for
> > trouble on the human side of things, entirely aside from allowing them in
> > filenames, dealing with case-insensitive filesystems, and so on.  Having a
> > nice human readable name for the web page, PKG-INFO, and description are
> > one thing, but having it used for filenames, URLs, and database keys is
> > quite another.
>
>I believe what you're proposing would require changing Python itself so it
>enforces restrictions on package names (ie. all lower-case, very limited
>punctuation, no whitespace). I think that's a good idea, but I also think at
>this point that the cat's out of the bag :(

Python doesn't let you use spaces and arbitrary punctuation in package 
names, so perhaps I've misunderstood you.

Also, just in case you've misunderstood me, I'm referring above to 
*project* names, not package names.  For example, PEAK has its project name 
registered as PEAK on PyPI, but its Python package name (that you actually 
import) is 'peak'.  I'm referring above only to project names, not package 
names.


From richardjones at optushome.com.au  Sat Sep 24 00:45:36 2005
From: richardjones at optushome.com.au (Richard Jones)
Date: Sat, 24 Sep 2005 08:45:36 +1000
Subject: [Catalog-sig] [Distutils]  setuptools or PyPI problem...?
In-Reply-To: <5.1.1.6.0.20050923113747.01b77950@mail.telecommunity.com>
References: <5.1.1.6.0.20050922232636.01b5fc40@mail.telecommunity.com>
	<5.1.1.6.0.20050923113747.01b77950@mail.telecommunity.com>
Message-ID: <200509240845.41561.richardjones@optushome.com.au>

On Sat, 24 Sep 2005 01:40 am, Phillip J. Eby wrote:
> At 01:37 PM 9/23/2005 +1000, Richard Jones wrote:
> >I believe what you're proposing would require changing Python itself so it
> >enforces restrictions on package names (ie. all lower-case, very limited
> >punctuation, no whitespace). I think that's a good idea, but I also think
> > at this point that the cat's out of the bag :(
>
> Python doesn't let you use spaces and arbitrary punctuation in package
> names, so perhaps I've misunderstood you.
>
> Also, just in case you've misunderstood me, I'm referring above to
> *project* names, not package names.  For example, PEAK has its project name
> registered as PEAK on PyPI, but its Python package name (that you actually
> import) is 'peak'.  I'm referring above only to project names, not package
> names.

By "package name" I mean the distutils package name.


     Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.python.org/pipermail/catalog-sig/attachments/20050924/7a409c39/attachment.pgp

From pje at telecommunity.com  Sat Sep 24 02:10:30 2005
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 23 Sep 2005 20:10:30 -0400
Subject: [Catalog-sig] [Distutils]  setuptools or PyPI problem...?
In-Reply-To: <200509240845.41561.richardjones@optushome.com.au>
References: <5.1.1.6.0.20050923113747.01b77950@mail.telecommunity.com>
	<5.1.1.6.0.20050922232636.01b5fc40@mail.telecommunity.com>
	<5.1.1.6.0.20050923113747.01b77950@mail.telecommunity.com>
Message-ID: <5.1.1.6.0.20050923201002.01b649c8@mail.telecommunity.com>

At 08:45 AM 9/24/2005 +1000, Richard Jones wrote:
>On Sat, 24 Sep 2005 01:40 am, Phillip J. Eby wrote:
> > At 01:37 PM 9/23/2005 +1000, Richard Jones wrote:
> > >I believe what you're proposing would require changing Python itself so it
> > >enforces restrictions on package names (ie. all lower-case, very limited
> > >punctuation, no whitespace). I think that's a good idea, but I also think
> > > at this point that the cat's out of the bag :(
> >
> > Python doesn't let you use spaces and arbitrary punctuation in package
> > names, so perhaps I've misunderstood you.
> >
> > Also, just in case you've misunderstood me, I'm referring above to
> > *project* names, not package names.  For example, PEAK has its project name
> > registered as PEAK on PyPI, but its Python package name (that you actually
> > import) is 'peak'.  I'm referring above only to project names, not package
> > names.
>
>By "package name" I mean the distutils package name.

Okay, so I still don't understand why this requires "changing Python 
itself".  Could you explain?


From richardjones at optushome.com.au  Sat Sep 24 04:45:21 2005
From: richardjones at optushome.com.au (Richard Jones)
Date: Sat, 24 Sep 2005 12:45:21 +1000
Subject: [Catalog-sig] [Distutils]  setuptools or PyPI problem...?
In-Reply-To: <5.1.1.6.0.20050923201002.01b649c8@mail.telecommunity.com>
References: <5.1.1.6.0.20050923113747.01b77950@mail.telecommunity.com>
	<5.1.1.6.0.20050923201002.01b649c8@mail.telecommunity.com>
Message-ID: <200509241245.25802.richardjones@optushome.com.au>

On Sat, 24 Sep 2005 10:10 am, Phillip J. Eby wrote:
> Okay, so I still don't understand why this requires "changing Python
> itself".  Could you explain?

Distutils metadata capture is implemented in the Python core. We would want to 
implement any name restrictions there, surely? Otherwise people only get an 
error when attempting to use setuptools or register with PyPI, which would be 
just annoying.


    Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.python.org/pipermail/catalog-sig/attachments/20050924/0025fbd9/attachment.pgp

From fdrake at gmail.com  Sat Sep 24 05:40:21 2005
From: fdrake at gmail.com (Fred Drake)
Date: Fri, 23 Sep 2005 23:40:21 -0400
Subject: [Catalog-sig] [Distutils] setuptools or PyPI problem...?
In-Reply-To: <200509241245.25802.richardjones@optushome.com.au>
References: <5.1.1.6.0.20050923113747.01b77950@mail.telecommunity.com>
	<5.1.1.6.0.20050923201002.01b649c8@mail.telecommunity.com>
	<200509241245.25802.richardjones@optushome.com.au>
Message-ID: <9cee7ab8050923204020fb2eef@mail.gmail.com>

On 9/23/05, Richard Jones <richardjones at optushome.com.au> wrote:
> Distutils metadata capture is implemented in the Python core. We would want to
> implement any name restrictions there, surely? Otherwise people only get an
> error when attempting to use setuptools or register with PyPI, which would be
> just annoying.

The use of distutils should not imply the use of PyPI.  Perhaps we'd
want distutils to issue a warning when building a distribution if the
naming conventions weren't acceptable, but that's the most we'd want. 
That should be something that could easily be turned off for a site or
an individual.


  -Fred

--
Fred L. Drake, Jr.    <fdrake at gmail.com>
Zope Corporation

From pje at telecommunity.com  Sat Sep 24 07:45:01 2005
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sat, 24 Sep 2005 01:45:01 -0400
Subject: [Catalog-sig] [Distutils] setuptools or PyPI problem...?
In-Reply-To: <9cee7ab8050923204020fb2eef@mail.gmail.com>
References: <200509241245.25802.richardjones@optushome.com.au>
	<5.1.1.6.0.20050923113747.01b77950@mail.telecommunity.com>
	<5.1.1.6.0.20050923201002.01b649c8@mail.telecommunity.com>
	<200509241245.25802.richardjones@optushome.com.au>
Message-ID: <5.1.1.6.0.20050924012942.01b65c50@mail.telecommunity.com>

At 11:40 PM 9/23/2005 -0400, Fred Drake wrote:
>On 9/23/05, Richard Jones <richardjones at optushome.com.au> wrote:
> > Distutils metadata capture is implemented in the Python core. We would 
> want to
> > implement any name restrictions there, surely? Otherwise people only get an
> > error when attempting to use setuptools or register with PyPI, which 
> would be
> > just annoying.
>
>The use of distutils should not imply the use of PyPI.  Perhaps we'd
>want distutils to issue a warning when building a distribution if the
>naming conventions weren't acceptable, but that's the most we'd want.
>That should be something that could easily be turned off for a site or
>an individual.

Not only that, but I'm not suggesting we ban those characters from 
names.  I'm suggesting merely that we strip them in a uniform way.  The 
error message would be "somebody already has a project with a name that's 
too similar to yours", not "you have unacceptable characters in your 
project name".  :)

I'm suggesting, in other words, that "Foo*Bar" and "Foo!Bar" simply not be 
considered unique project names, not that whichever project registers the 
name first can't use it with funky punctuation in PKG-INFO and display it 
on their PyPI page that way.  (I would also suggest that we clarify the 
rules for determining project name uniqueness and recommend people follow 
them for simplicity's sake, of course.)

I'm also suggesting that if somebody goes to the URL "/pypi/foo--bar", it 
would still pull up the "Foo*Bar" project if that's the one that's 
registered, because canonicalizing 'foo--bar' should yield the same unique 
key as canonicalizing 'Foo*Bar'.  (This is particularly nice for 
EasyInstall users, since it wouldn't need to fall back to pulling down the 
entire index to do a case-insensitive search when they don't match 
someone's CreativeCAPS in a project name.)

In other words, all user inputs (URL or otherwise) should be normalized for 
key storage and lookup, distinct from the human-readable name of the 
package.  (Setuptools implements this for eggs by having distinct 
"project_name" and "key" attributes.)

This approach has a few important features:

1. It can be implemented without renaming existing packages, unless there 
are actual conflicts in PyPI today

2. It can be implemented without any need for co-operation from package 
authors, because it's strictly a PyPI-side change.

3. It allows authors to fully express their creativity in naming

4. It allows end-users to ignore the authors' creativity  :)

The principal downside, of course, is that it's probably not a minor change 
to the PyPI code base, with respect to the "two names" issue, or with 
respect to how lookups are done.  Which is why I haven't been hounding 
Richard to do it.  Well, maybe just a little.  ;)


From tinuviel at sparcs.kaist.ac.kr  Sat Sep 24 06:31:14 2005
From: tinuviel at sparcs.kaist.ac.kr (Seo Sanghyeon)
Date: Sat, 24 Sep 2005 13:31:14 +0900
Subject: [Catalog-sig] PyPI problems
Message-ID: <20050924043114.GA32552@sparcs.kaist.ac.kr>

I found following problems. Any idea?
Confusingly, these seem to be specific to following 3 packages only.

http://www.python.org/pypi/gadfly/1.0.0 works,
http://www.python.org/pypi/gadfly is 404.

http://www.python.org/pypi/Numeric/22.0 works,
http://www.python.org/pypi/Numeric is 404.

http://www.python.org/pypi/PyXML/0.8.2 works,
http://www.python.org/pypi/PyXML is 404.

Seo Sanghyeon