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. 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 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. 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 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. 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 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