From zooko at zooko.com Thu May 1 00:21:13 2008 From: zooko at zooko.com (zooko) Date: Wed, 30 Apr 2008 16:21:13 -0600 Subject: [Distutils] shal we redefine "module" and "package"? Message-ID: <50D35C20-ED3D-4A7D-965D-D5BBD76EDDC7@zooko.com> Folks: Here's an experiment you can perform. Round up a Python programmer and ask him the following three questions: Q1. You type "import foo" and it works. What kind of thing is foo? Q2. You go to the Python package index and download something named "bar-1.0.0.tar.gz". What kind of thing is bar? Q3. What is a "distribution"? I'm willing to bet that you will get the following answers: A1. foo is a module. A2. bar is a package. A3. A distribution is a version of Linux that comes with a lot of Free Software. Unfortunately these answers aren't quite right. A "package" is actually a directory containing an __init__.py file, and a distribution is actually what you think of when you say "package" -- a reusable package of Python code that you can, for example, get from the Python package index. Educational efforts such as the Python tutorial and the distutils docs have not succeeded in training Python programmers to understand the terminology for these things as used by the Python implementors, so perhaps instead the implementors should start using the terminology understood by the programmers: 1. A "module" shall henceforth be the name for either a foo.py file (a single-file module), or a directory with an __init__.py in it (a directory module). 2. A "package" shall henceforth be the name of the thing that is currently called a "distribution". Regards, Zooko who doesn't mind stirring up trouble on occasion... From ncoghlan at gmail.com Thu May 1 01:08:25 2008 From: ncoghlan at gmail.com (Nick Coghlan) Date: Thu, 01 May 2008 09:08:25 +1000 Subject: [Distutils] [Python-Dev] shal we redefine "module" and "package"? In-Reply-To: <50D35C20-ED3D-4A7D-965D-D5BBD76EDDC7@zooko.com> References: <50D35C20-ED3D-4A7D-965D-D5BBD76EDDC7@zooko.com> Message-ID: <4818FBE9.3040805@gmail.com> zooko wrote: > Folks: > > Here's an experiment you can perform. Round up a Python programmer and > ask him the following three questions: > > Q1. You type "import foo" and it works. What kind of thing is foo? foo is a package or a module. Not enough information is provide here to say which. > Q2. You go to the Python package index and download something named > "bar-1.0.0.tar.gz". What kind of thing is bar? bar is a package, a module, or a collection of a number of these things. Again, not enough information is provided in the question to say which is actually the case. Cheers, Nick. P.S. People, including programmers, are often sloppy with terminology. This is not a new problem. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org From glyph at divmod.com Thu May 1 01:11:46 2008 From: glyph at divmod.com (glyph at divmod.com) Date: Wed, 30 Apr 2008 23:11:46 -0000 Subject: [Distutils] [Python-Dev] shal we redefine "module" and "package"? In-Reply-To: References: <50D35C20-ED3D-4A7D-965D-D5BBD76EDDC7@zooko.com> Message-ID: <20080430231146.25821.1286760271.divmod.xquotient.4498@joule.divmod.com> On 10:53 pm, steve at holdenweb.com wrote: >zooko wrote: >>Unfortunately these answers aren't quite right. A "package" is >>actually a directory containing an __init__.py file, and a >>distribution is actually what you think of when you say "package" -- a >>reusable package of Python code that you can, for example, get from >>the Python package index. The fact that the Python "package" index is a place where you get "distributions" does seem a bit weird to me, but this is not necessarily a problem that can be fixed. Ambiguity is part of human language. Perhaps suggest transliterations of these terms for talking about python in lojban? :) >>1. A "module" shall henceforth be the name for either a foo.py file >>(a single-file module), or a directory with an __init__.py in it (a >>directory module). I have a less disruptive counterproposal. How about just starting to refer to directories (or "folders", or zip entries) with '__init__.py' in them as "package modules"? A package is-a module anyway. >>2. A "package" shall henceforth be the name of the thing that is >>currently called a "distribution". I belive a multi-word term here would be similarly more memorable and precise. A "package distribution" would include the more familiar term while still being specific, consistent with the old terminology, and correct. Using a qualifying word is probably a good idea in this context anyway. I usually say "debian package", "RPM", "MSI", or "tarball" unless I'm specifically talking about "packages for your platform", almost always in the phrase, "please do not use distutils to do a system install of Twisted, use the specific package for your platform". >-1 I do, however, agree with Steve emphatically on your original proposal. Changing the terminology now will make billions upon billions of Python web pages, modules (c.f. twisted.python.modules.PythonModule.isPackage()) documents, and searchable message archives obsolete, not to mention that 90% of the community will probably ignore you and use the old terminology anyway, creating more confusion than it eliminates. From greg.ewing at canterbury.ac.nz Thu May 1 01:17:12 2008 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 01 May 2008 11:17:12 +1200 Subject: [Distutils] [Python-Dev] shal we redefine "module" and "package"? In-Reply-To: <4818FBE9.3040805@gmail.com> References: <50D35C20-ED3D-4A7D-965D-D5BBD76EDDC7@zooko.com> <4818FBE9.3040805@gmail.com> Message-ID: <4818FDF8.9040506@canterbury.ac.nz> Nick Coghlan wrote: > zooko wrote: > >> Q1. You type "import foo" and it works. What kind of thing is foo? > > foo is a package or a module. Not enough information is provide here to > say which. Actually, it could be anything! But it's *probably* a module (or package, but a package is also a module, if we're being fussy about terminology). -- Greg From bignose+hates-spam at benfinney.id.au Thu May 1 04:37:58 2008 From: bignose+hates-spam at benfinney.id.au (Ben Finney) Date: Thu, 01 May 2008 12:37:58 +1000 Subject: [Distutils] shal we redefine "module" and "package"? References: <50D35C20-ED3D-4A7D-965D-D5BBD76EDDC7@zooko.com> Message-ID: <87zlra21h5.fsf@benfinney.id.au> zooko writes: > I'm willing to bet that you will get the following answers: > > A1. foo [from 'import foo'] is a module. > > A2. bar [of 'bar-1.2.3.tar.gz'] is a package. > > A3. A distribution is a version of Linux that comes with a lot of > Free Software. > > > Unfortunately these answers aren't quite right. More accurately, they're right in the context from which the speaker learned them. > A "package" is actually a directory containing an __init__.py file, > and a distribution is actually what you think of when you say > "package" -- a reusable package of Python code that you can, for > example, get from the Python package index. Only within Python's terminology. This, of course, conflicts with the meanings that adhere to those words just about everywhere else on the user's operating system. > Educational efforts such as the Python tutorial and the distutils > docs have not succeeded in training Python programmers to understand > the terminology for these things as used by the Python implementors, More accurately, the meanings you list in the hypothetical responses above are entrenched and more useful for general use. > so perhaps instead the implementors should start using the > terminology understood by the programmers: In principle this would be good. However: > 1. A "module" shall henceforth be the name for either a foo.py file > (a single-file module), or a directory with an __init__.py in it (a > directory module). How then to distinguish between these? They're clearly separate concepts, and I think they need distinct terms. > 2. A "package" shall henceforth be the name of the thing that is > currently [in Python terminology] called a "distribution". That one would be good. You then have the converse problem of changing the use of terminology that is currently entrenched in existing Python documentation and minds :-) -- \ "Always code as if the guy who ends up maintaining your code | `\ will be a violent psychopath who knows where you live." ?John | _o__) F. Woods | Ben Finney From mhearne at usgs.gov Thu May 1 18:53:52 2008 From: mhearne at usgs.gov (Michael Hearne) Date: Thu, 1 May 2008 10:53:52 -0600 Subject: [Distutils] easy_install path Message-ID: I'm having a problem with easy_install and a library I just installed. I have a Mac OS 10.5 (Leopard), and I used the SciPy SuperPack installer (http://macinscience.org/?page_id=6) to install a whole bunch of scientific packages, including matplotlib. I then used easy_install to install Basemap, which is a "toolkit" based on matplotlib. The usual instructions for Basemap have the import statement like this: from matplotlib.toolkits.basemap import Basemap However, when I try this in Python, I get an ImportError. This obviously has something to do with the path that Python uses to find libraries, and I found an easy_install.pth file that looks like this: ------------------------------------------------------------------ ./setuptools-0.6c8-py2.5.egg ./readline-2.5.1-py2.5-macosx-10.5-i386.egg ./ipython-0.8.3.svn.r3001-py2.5.egg ./numpy-1.1.0.dev5077-py2.5-macosx-10.3-i386.egg ./matplotlib-0.98pre-py2.5-macosx-10.3-i386.egg ./scipy-0.7.0.dev4174-py2.5-macosx-10.3-i386.egg ./pymc-2.0DEV_r709-py2.5-macosx-10.3-i386.egg ./nose-0.10.1-py2.5.egg ./basemap-0.9.9.1-py2.5-macosx-10.5-i386.egg import sys; new=sys.path[sys.__plen:]; del sys.path[sys.__plen:]; p=getattr(sys,'__egginsert',0); sys.path[p:p]=new; sys.__egg insert = p+len(new) ------------------------------------------------------------------ Any clues as to what is going on, and how I can fix the problem? Thanks, Mike ------------------------------------------------------ Michael Hearne mhearne at usgs.gov (303) 273-8620 USGS National Earthquake Information Center 1711 Illinois St. Golden CO 80401 Senior Software Engineer Synergetics, Inc. ------------------------------------------------------ From pfein at pobox.com Thu May 1 20:00:21 2008 From: pfein at pobox.com (Pete) Date: Thu, 1 May 2008 14:00:21 -0400 Subject: [Distutils] Setuptools Bug: all files installed +x In-Reply-To: <1208894208.15868.186.camel@portableevil.develix.com> References: <2024A24F-7BEA-437B-96F4-AB8A6D61AFC6@pobox.com> <20080421194238.DD2AB3A4070@sparrow.telecommunity.com> <100418B3-CA0B-45EE-AE0A-F6C25D685C02@pobox.com> <20080421220124.8C9283A4070@sparrow.telecommunity.com> <4D80DB69-BB12-457A-B060-E95793A79CD9@pobox.com> <20080422161916.D33BE3A4070@sparrow.telecommunity.com> <1208894208.15868.186.camel@portableevil.develix.com> Message-ID: On Apr 22, 2008, at 3:56 PM, Cliff Wells wrote: > > On Tue, 2008-04-22 at 12:19 -0400, Phillip J. Eby wrote: >> At 11:49 AM 4/22/2008 -0400, Pete wrote: >>> On Apr 21, 2008, at 6:01 PM, Phillip J. Eby wrote: >>> >>>> At 04:23 PM 4/21/2008 -0400, Pete wrote: >>>>> I'm not looking for explicit testing support from setuptools for >>>>> testing here - I'm just asking that a bug that breaks a 3rd party >>>>> testing package be fixed. >>>> >>>> You haven't stated anything yet that sounds like an actual bug to >>>> me. >>> >>> What about the dangerous & broken complaint? >> >> Which I don't yet understand, let alone agree with. Simply asserting >> over and over that it's bad and dangerous doesn't help. > > He's also right in that arbitrarily setting the execute bit apparently > serves no explainable purpose (otherwise I assume you'd have > provided an > explanation by now), so the onus of explaining why this is a desirable > behavior comes back to setuptools. Did a decision ever get made here? I don't mean to be a nag, but this is continuing to cause problems for me and my users. Just wanted to make sure it doesn't get lost/forgotten. This is why people have bug trackers y'know. ;-( From zooko at zooko.com Thu May 1 21:59:05 2008 From: zooko at zooko.com (zooko) Date: Thu, 1 May 2008 13:59:05 -0600 Subject: [Distutils] Setuptools Bug: all files installed +x In-Reply-To: References: <2024A24F-7BEA-437B-96F4-AB8A6D61AFC6@pobox.com> <20080421194238.DD2AB3A4070@sparrow.telecommunity.com> <100418B3-CA0B-45EE-AE0A-F6C25D685C02@pobox.com> <20080421220124.8C9283A4070@sparrow.telecommunity.com> <4D80DB69-BB12-457A-B060-E95793A79CD9@pobox.com> <20080422161916.D33BE3A4070@sparrow.telecommunity.com> <1208894208.15868.186.camel@portableevil.develix.com> Message-ID: On May 1, 2008, at 12:00 PM, Pete wrote: > Did a decision ever get made here? I don't mean to be a nag, but > this is continuing to cause problems for me and my users. Just > wanted to make sure it doesn't get lost/forgotten. > > This is why people have bug trackers y'know. ;-( I agree that bug trackers are important for this sort of reason. You're welcome to use the one that I set up: http://allmydata.org/trac/setuptools/report/1 PJE hasn't agreed to use it so far, but on the other hand he doesn't have to use it for it to serve as a record of the status of issues. Regards, Zooko From zooko at zooko.com Thu May 1 22:25:27 2008 From: zooko at zooko.com (zooko) Date: Thu, 1 May 2008 14:25:27 -0600 Subject: [Distutils] [Python-Dev] shal we redefine "module" and "package"? In-Reply-To: <20080430231146.25821.1286760271.divmod.xquotient.4498@joule.divmod.com> References: <50D35C20-ED3D-4A7D-965D-D5BBD76EDDC7@zooko.com> <20080430231146.25821.1286760271.divmod.xquotient.4498@joule.divmod.com> Message-ID: <1AAD84FC-602B-42E5-84E7-31045DE78AAF@zooko.com> On Apr 30, 2008, at 5:11 PM, glyph at divmod.com wrote: > I have a less disruptive counterproposal. How about just starting > to refer to directories (or "folders", or zip entries) with > '__init__.py' in them as "package modules"? A package is-a module > anyway. That's a good idea. > I belive a multi-word term here would be similarly more memorable > and precise. A "package distribution" would include the more > familiar term while still being specific, consistent with the old > terminology, and correct. Using a qualifying word is probably a > good idea in this context anyway. I usually say "debian package", > "RPM", "MSI", or "tarball" unless I'm specifically talking about > "packages for your platform", That's a good one too. > almost always in the phrase, "please do not use distutils to do a > system install of Twisted, use the specific package for your > platform". This is a tangent, but why do you give that advice? I typically give people the opposite advice on how to install Twisted. > I do, however, agree with Steve emphatically on your original > proposal. Changing the terminology now will make billions upon > billions of Python web pages, modules (c.f. > twisted.python.modules.PythonModule.isPackage()) documents, and > searchable message archives obsolete, not to mention that 90% of > the community will probably ignore you and use the old terminology > anyway, creating more confusion than it eliminates. I suspect 90% of the community already uses my proposed terminology -- that was my original challenge to round up a Python programmer and find out. But I agree that my proposal would contribute to confusion and disruption, and I like your counterproposals better, at least for now. Directories, folders, or zip entries with __init__.py in them are "package modules", and Python packages are "package distributions". Regards, Zooko From glyph at divmod.com Thu May 1 22:51:37 2008 From: glyph at divmod.com (glyph at divmod.com) Date: Thu, 01 May 2008 20:51:37 -0000 Subject: [Distutils] Why not distutils? (was Re: [Python-Dev] shal we redefine "module" and "package"?) In-Reply-To: <1AAD84FC-602B-42E5-84E7-31045DE78AAF@zooko.com> References: <50D35C20-ED3D-4A7D-965D-D5BBD76EDDC7@zooko.com> <20080430231146.25821.1286760271.divmod.xquotient.4498@joule.divmod.com> <1AAD84FC-602B-42E5-84E7-31045DE78AAF@zooko.com> Message-ID: <20080501205137.25821.1948581346.divmod.xquotient.7096@joule.divmod.com> I'm not on distutils-sig, but this is probably of little interest to python-dev. Please Cc: me if you think my continued input would be useful to this discussion. On 08:25 pm, zooko at zooko.com wrote: >>almost always in the phrase, "please do not use distutils to do a >>system install of Twisted, use the specific package for your >>platform". > >This is a tangent, but why do you give that advice? I typically give >people the opposite advice on how to install Twisted. The #1 reason: * distutils does not provide an uninstaller. This means that a user who has installed a Python library - but especially a package like Twisted, which uses a shared namespace with other libraries that use it, twisted.plugins - can't easily get rid of it. I only ever use 'setup.py' in conjunction with '--prefix'; in my opinion, the *default* behavior of distutils should be "--prefix ~/.local". Definitely not the only reason, though. Even if distutils had a great uninstaller, I still probably wouldn't recommend it... * distutils will interfere with the system package manager, potentially breaking it, by writing files to locations reserved for the system package manager (/usr, et. al.) * distutils won't uninstall a system-installed version of the package first, so if you use e.g. --force to overwrite your system files, you may end up with leftover system packaged (incompatible, earlier-version) plugins or modules which break your distutils install * running arbitrary, non-vendor-supported code as root as a matter of habit is, in my humble opinion, bad; distutils requires you to run as root for the default behavior to work. the system package manager typically requires root permission too, but at least it's the sort of thing which has been audited. * not only can you not reverse the process, there's no way to *tell* if distutils has crapped all over your system installation of a particular package * setuptools causes seemingly random breakages (in packages which support it), and I don't want to deal with bug reports from users related to packaging; packagers are capable of dealing with setuptools' interactions with the platform and creating a nice, neat bundle that works as expected. * when you say "distutils", what do you mean? running 'setup.py' from some random revision of trunk? doing 'sdist' from trunk, then install? Using operating-system packages at least suggests that you're using a release, or if not an actual release, you've gone through something approximating the actual release/build process that we suggest for users. * if the user is installing for development anyway, and not for deployment, then why bother doing any installation step at all? It's probably better to just drop an SVN checkout on PYTHONPATH somewhere. And, finally... * why bother having installers prepared for particular systems, if they are not the preferred way of doing things? If and when distutils is ready to be the thing I will suggest to users, I imagine that we'll stop having operating system packages. (Of course, that begs the question why distutils would have commands like "bdist_wininst" - it's difficult to beat the native packages for convenience.) From zooko at zooko.com Thu May 1 23:17:19 2008 From: zooko at zooko.com (zooko) Date: Thu, 1 May 2008 15:17:19 -0600 Subject: [Distutils] Why not distutils? (was Re: [Python-Dev] shal we redefine "module" and "package"?) In-Reply-To: <20080501205137.25821.1948581346.divmod.xquotient.7096@joule.divmod.com> References: <50D35C20-ED3D-4A7D-965D-D5BBD76EDDC7@zooko.com> <20080430231146.25821.1286760271.divmod.xquotient.4498@joule.divmod.com> <1AAD84FC-602B-42E5-84E7-31045DE78AAF@zooko.com> <20080501205137.25821.1948581346.divmod.xquotient.7096@joule.divmod.com> Message-ID: <31E9DA28-341C-4E04-B3D0-1974D0DA739D@zooko.com> On May 1, 2008, at 2:51 PM, glyph at divmod.com wrote: > I'm not on distutils-sig, but this is probably of little interest > to python-dev. Please Cc: me if you think my continued input would > be useful to this discussion. I use distutils (or setuptools) plus GNU stow to solve the following subset of your complaints: > The #1 reason: > > * distutils does not provide an uninstaller. ... > * distutils will interfere with the system package manager, > potentially breaking it, by writing files to locations reserved for > the system package manager (/usr, et. al.) > * distutils won't uninstall a system-installed version of the > package first, so if you use e.g. --force to overwrite your system > files, you may end up with leftover system packaged (incompatible, > earlier-version) plugins or modules which break your distutils install > * running arbitrary, non-vendor-supported code as root as a matter > of habit is, in my humble opinion, bad; distutils requires you to > run as root for the default behavior to work. the system package > manager typically requires root permission too, but at least it's > the sort of thing which has been audited. > * not only can you not reverse the process, there's no way to > *tell* if distutils has crapped all over your system installation > of a particular package GNU stow + distutils or setuptools solves all of the above for me. It does not solve the following: > * setuptools causes seemingly random breakages (in packages which > support it), and I don't want to deal with bug reports from users > related to packaging; packagers are capable of dealing with > setuptools' interactions with the platform and creating a nice, > neat bundle that works as expected. > * when you say "distutils", what do you mean? running 'setup.py' > from some random revision of trunk? doing 'sdist' from trunk, then > install? Using operating-system packages at least suggests that > you're using a release, or if not an actual release, you've gone > through something approximating the actual release/build process > that we suggest for users. > * if the user is installing for development anyway, and not for > deployment, then why bother doing any installation step at all? > It's probably better to just drop an SVN checkout on PYTHONPATH > somewhere. > And, finally... > > * why bother having installers prepared for particular systems, if > they are not the preferred way of doing things? If and when > distutils is ready to be the thing I will suggest to users, I > imagine that we'll stop having operating system packages. (Of > course, that begs the question why distutils would have commands > like "bdist_wininst" - it's difficult to beat the native packages > for convenience.) Why indeed? I personally prefer to distribute my code in the form of source .tar.gz's which are to be installed either with easy_install or by untarring them and running "setup.py", and I prefer to re-use code from other people in that same format. Regards, Zooko From jim at zope.com Thu May 1 23:36:41 2008 From: jim at zope.com (Jim Fulton) Date: Thu, 1 May 2008 17:36:41 -0400 Subject: [Distutils] Why not distutils? (was Re: [Python-Dev] shal we redefine "module" and "package"?) In-Reply-To: <20080501205137.25821.1948581346.divmod.xquotient.7096@joule.divmod.com> References: <50D35C20-ED3D-4A7D-965D-D5BBD76EDDC7@zooko.com> <20080430231146.25821.1286760271.divmod.xquotient.4498@joule.divmod.com> <1AAD84FC-602B-42E5-84E7-31045DE78AAF@zooko.com> <20080501205137.25821.1948581346.divmod.xquotient.7096@joule.divmod.com> Message-ID: <1D9A1011-3E2C-4348-B354-B4943DD79322@zope.com> On May 1, 2008, at 4:51 PM, glyph at divmod.com wrote: > I'm not on distutils-sig, but this is probably of little interest to > python-dev. Please Cc: me if you think my continued input would be > useful to this discussion. > > On 08:25 pm, zooko at zooko.com wrote: >>> almost always in the phrase, "please do not use distutils to do a >>> system install of Twisted, use the specific package for your >>> platform". >> >> This is a tangent, but why do you give that advice? I typically >> give people the opposite advice on how to install Twisted. > > The #1 reason: > > * distutils does not provide an uninstaller. > > This means that a user who has installed a Python library - but > especially a package like Twisted, which uses a shared namespace > with other libraries that use it, twisted.plugins - can't easily get > rid of it. I only ever use 'setup.py' in conjunction with '-- > prefix'; in my opinion, the *default* behavior of distutils should > be "--prefix ~/.local". > > Definitely not the only reason, though. Even if distutils had a > great uninstaller, I still probably wouldn't recommend it... > > * distutils will interfere with the system package manager, > potentially breaking it, by writing files to locations reserved for > the system package manager (/usr, et. al.) > * distutils won't uninstall a system-installed version of the > package first, so if you use e.g. --force to overwrite your system > files, you may end up with leftover system packaged (incompatible, > earlier-version) plugins or modules which break your distutils install > * running arbitrary, non-vendor-supported code as root as a matter > of habit is, in my humble opinion, bad; distutils requires you to > run as root for the default behavior to work. the system package > manager typically requires root permission too, but at least it's > the sort of thing which has been audited. > * not only can you not reverse the process, there's no way to *tell* > if distutils has crapped all over your system installation of a > particular package > * setuptools causes seemingly random breakages (in packages which > support it), and I don't want to deal with bug reports from users > related to packaging; packagers are capable of dealing with > setuptools' interactions with the platform and creating a nice, neat > bundle that works as expected. > * when you say "distutils", what do you mean? running 'setup.py' > from some random revision of trunk? doing 'sdist' from trunk, then > install? Using operating-system packages at least suggests that > you're using a release, or if not an actual release, you've gone > through something approximating the actual release/build process > that we suggest for users. > * if the user is installing for development anyway, and not for > deployment, then why bother doing any installation step at all? > It's probably better to just drop an SVN checkout on PYTHONPATH > somewhere. > > And, finally... > > * why bother having installers prepared for particular systems, if > they are not the preferred way of doing things? If and when > distutils is ready to be the thing I will suggest to users, I > imagine that we'll stop having operating system packages. (Of > course, that begs the question why distutils would have commands > like "bdist_wininst" - it's difficult to beat the native packages > for convenience.) These are very good arguments for not using distutils to install packages into a system Python. Well said. I'll note that I *never* use distutils that way. :) (I may be in the minority though.) Jim -- Jim Fulton Zope Corporation From mhammond at skippinet.com.au Fri May 2 12:58:15 2008 From: mhammond at skippinet.com.au (Mark Hammond) Date: Fri, 2 May 2008 20:58:15 +1000 Subject: [Distutils] setuptools on 64 bit Windows broken? In-Reply-To: <20080421201819.GQ64048@nexus.in-nomine.org> References: <20080421201819.GQ64048@nexus.in-nomine.org> Message-ID: <061501c8ac43$709ef0f0$51dcd2d0$@com.au> Jergoen brought this thread to my attention via python-dev... > Sent: Tuesday, 22 April 2008 6:18 AM > Right now setuptools on Windows x64 with 64-bits Python 2.5 is > (partially) > broken. > > The error shown is: > > Cannot find Python executable C:\Python25\python.exe > > when running easy_install. The phrase comes from launcher.c which is > compiled via MingW to cli.exe and gui.exe. > Both of these are present in the > setuptools repository and are 32-bits only for all I can determine FYI, there isn't really a concept of "32-bits only" - 32bit programs will run on 64bit windows just fine, as you are seeing - but yes, the fact they are 32bit is probably relevant. > (using > file). I have not thoroughly checked it yet (due to being written in > Unix-C, > even though it's aimed at Windows), but my guess is it's using some API > calls which fail on 64-bits Windows. I see there's a mingw-64 toolkit > on the > 'net nowadays. Has anyone tried this yet? Is it indeed an API issue? I suspect that the issue is that a 32bit cli.exe or gui.exe is attempting to LoadLibrary a 64bit executable and failing (specifically, loadable_exe() in launcher.c) The bdist_wininst command in distutils recently faced a similar problem. The solution (which IIRC was part of http://bugs.python.org/issue2513) was to have 64bit specific executables and to use them when appropriate (and bdist_wininst also supported cross-compilation so you can generate the 64bit executables on a 32bit platform, and although quite simple, it isn't a requirement). As mentioned on the python-dev thread, you will also want to modify setuptools to use the result of distutils.util.get_platform() in the generated filenames, and it's also likely you will need to modify other parts of setuptools to use that platform name when looking for dependencies etc. Looking at the recent history of bdist_wininst.py should offer more clues. My experience with setuptools is very limited so I hope I haven't missed the point... Cheers, Mark From pfein at pobox.com Fri May 2 18:30:34 2008 From: pfein at pobox.com (Pete) Date: Fri, 2 May 2008 12:30:34 -0400 Subject: [Distutils] setuptools: Spelling < 3.1.0beta3 ? Message-ID: <1291CF2F-150A-4389-AEBF-DAC6A854BB19@pobox.com> Hi- What's the proper way to spell "any version in the 3.0.x series" if a project has a 3.1.0beta3 release? Specifically, CherryPy has both 3.0.2 and 3.1.0beta3 releases. I'd like to depend on any 3.0.x I've tried both 'CherryPy < 3.1' and 'CherryPy < 3.1.0' in my install_requires, and both cause setuptools to pull 3.1.0beta3. I realize I can use 'CherryPy == 3.0.2' but that defeats the "any 3.0.x" idea... --Pete From lxander.m at gmail.com Fri May 2 18:48:26 2008 From: lxander.m at gmail.com (Alexander Michael) Date: Fri, 2 May 2008 12:48:26 -0400 Subject: [Distutils] Fwd: setuptools: Spelling < 3.1.0beta3 ? In-Reply-To: <525f23e80805020948u73aeb021y4dd0cfe83b79f2d4@mail.gmail.com> References: <1291CF2F-150A-4389-AEBF-DAC6A854BB19@pobox.com> <525f23e80805020948u73aeb021y4dd0cfe83b79f2d4@mail.gmail.com> Message-ID: <525f23e80805020948u14de4b60nc23ddf4bac7609a5@mail.gmail.com> On Fri, May 2, 2008 at 12:30 PM, Pete wrote: > Hi- > > What's the proper way to spell "any version in the 3.0.x series" if a > project has a 3.1.0beta3 release? > > Specifically, CherryPy has both 3.0.2 and 3.1.0beta3 releases. I'd like to > depend on any 3.0.x > > I've tried both 'CherryPy < 3.1' and 'CherryPy < 3.1.0' in my > install_requires, and both cause setuptools to pull 3.1.0beta3. > > I realize I can use 'CherryPy == 3.0.2' but that defeats the "any 3.0.x" > idea... I find this surprising as well, but the answer is: >>> import pkg_resources >>> v = pkg_resources.parse_version >>> v('3.1.0beta3') < v('3.1.0') True >>> v('3.1.0beta3') < v('3.1.0a0') False I wish it was "easier" to say "3.1.x" (as in any final sub-point release in the 3 series) or "1.x" (as in any final version 1 release) which didn't allow development, alpha, beta, candidate, etc. releases. Is there? From bhendrix at enthought.com Fri May 2 19:02:30 2008 From: bhendrix at enthought.com (Bryce Hendrix) Date: Fri, 2 May 2008 12:02:30 -0500 Subject: [Distutils] Fwd: setuptools: Spelling < 3.1.0beta3 ? In-Reply-To: <525f23e80805020948u14de4b60nc23ddf4bac7609a5@mail.gmail.com> References: <1291CF2F-150A-4389-AEBF-DAC6A854BB19@pobox.com> <525f23e80805020948u73aeb021y4dd0cfe83b79f2d4@mail.gmail.com> <525f23e80805020948u14de4b60nc23ddf4bac7609a5@mail.gmail.com> Message-ID: <200805021202.30830.bhendrix@enthought.com> On Friday 02 May 2008 11:48:26 Alexander Michael wrote: > On Fri, May 2, 2008 at 12:30 PM, Pete wrote: > > Hi- > > > > What's the proper way to spell "any version in the 3.0.x series" if a > > project has a 3.1.0beta3 release? > > > > Specifically, CherryPy has both 3.0.2 and 3.1.0beta3 releases. I'd > > like to depend on any 3.0.x > > > > I've tried both 'CherryPy < 3.1' and 'CherryPy < 3.1.0' in my > > install_requires, and both cause setuptools to pull 3.1.0beta3. > > > > I realize I can use 'CherryPy == 3.0.2' but that defeats the "any > > 3.0.x" idea... > > I find this surprising as well, but the answer is: > >>> import pkg_resources > >>> v = pkg_resources.parse_version > >>> v('3.1.0beta3') < v('3.1.0') > > True > > >>> v('3.1.0beta3') < v('3.1.0a0') > > False > > I wish it was "easier" to say "3.1.x" (as in any final sub-point > release in the 3 series) or "1.x" (as in any final version 1 release) > which didn't allow development, alpha, beta, candidate, etc. releases. > Is there? When installing via easy_install, I typically say "<3.0.99", but I would never embed that requirement into code. A lot of our requirements are specified as "<3.1.0a" Bryce From aantny at gmail.com Sun May 4 10:04:10 2008 From: aantny at gmail.com (natan yellin) Date: Sun, 4 May 2008 11:04:10 +0300 Subject: [Distutils] Script Files, Prefix, and Uninstallation Message-ID: Hello, I'm relatively new to python, and I have a few questions related to distutils. 1) If I attempt to install script files without a .py extension, distutils installs them twice- once with a .py extension and once without. Is there a way to work around that? 2) Is there a way to change the default install prefix from /usr to /usr/local? 3) Is it possible to find the install prefix that was actually used. (e.g. if the user set --prefix to something other than /usr/local). I'd like to store the prefix in a file so that I can later uninstall from the correct prefix. (Or is there an easier way to uninstall that I'm missing?) Thanks in advance, Natan -------------- next part -------------- An HTML attachment was scrubbed... URL: From pje at telecommunity.com Sun May 4 19:49:38 2008 From: pje at telecommunity.com (Phillip J. Eby) Date: Sun, 04 May 2008 13:49:38 -0400 Subject: [Distutils] Fwd: setuptools: Spelling < 3.1.0beta3 ? In-Reply-To: <525f23e80805020948u14de4b60nc23ddf4bac7609a5@mail.gmail.co m> References: <1291CF2F-150A-4389-AEBF-DAC6A854BB19@pobox.com> <525f23e80805020948u73aeb021y4dd0cfe83b79f2d4@mail.gmail.com> <525f23e80805020948u14de4b60nc23ddf4bac7609a5@mail.gmail.com> Message-ID: <20080504174920.321B63A40D8@sparrow.telecommunity.com> At 12:48 PM 5/2/2008 -0400, Alexander Michael wrote: >On Fri, May 2, 2008 at 12:30 PM, Pete wrote: > > Hi- > > > > What's the proper way to spell "any version in the 3.0.x series" if a > > project has a 3.1.0beta3 release? > > > > Specifically, CherryPy has both 3.0.2 and 3.1.0beta3 > releases. I'd like to > > depend on any 3.0.x > > > > I've tried both 'CherryPy < 3.1' and 'CherryPy < 3.1.0' in my > > install_requires, and both cause setuptools to pull 3.1.0beta3. > > > > I realize I can use 'CherryPy == 3.0.2' but that defeats the "any 3.0.x" > > idea... > > I find this surprising as well, but the answer is: > > >>> import pkg_resources > >>> v = pkg_resources.parse_version > >>> v('3.1.0beta3') < v('3.1.0') > True > >>> v('3.1.0beta3') < v('3.1.0a0') > False Leading zeros before an alpha component are dropped from comparisons, so you could equally say '<3.1a'. However, what you really want is '<3.1dev', as 'dev' is the lowest-possible precedence pre-release tag. So, to say "any 3.0.x", you would need to say '>=3.0.1dev, <3.1dev' (assuming you wanted to include pre-release 3.0.x versions). > I wish it was "easier" to say "3.1.x" (as in any final sub-point > release in the 3 series) or "1.x" (as in any final version 1 release) > which didn't allow development, alpha, beta, candidate, etc. releases. > Is there? Not at the moment, no. From pje at telecommunity.com Sun May 4 19:51:42 2008 From: pje at telecommunity.com (Phillip J. Eby) Date: Sun, 04 May 2008 13:51:42 -0400 Subject: [Distutils] Script Files, Prefix, and Uninstallation In-Reply-To: References: Message-ID: <20080504175123.D09A93A4036@sparrow.telecommunity.com> At 11:04 AM 5/4/2008 +0300, natan yellin wrote: >Hello, >I'm relatively new to python, and I have a few questions related to distutils. > >1) If I attempt to install script files without a .py extension, >distutils installs them twice- once with a .py extension and once >without. Is there a way to work around that? I've never seen the behavior you're describing. You should probably post your setup.py for us to see what you're doing. >2) Is there a way to change the default install prefix from /usr to >/usr/local? You can change that systemwide by creating the appropriate config file. Please see the configuration file section of the "Installing Python Modules" manual. >3) Is it possible to find the install prefix that was actually used. >(e.g. if the user set --prefix to something other than /usr/local). >I'd like to store the prefix in a file so that I can later uninstall >from the correct prefix. (Or is there an easier way to uninstall >that I'm missing?) You can use the --record option to the install command to write a list of all files that were installed. From pje at telecommunity.com Sun May 4 20:13:50 2008 From: pje at telecommunity.com (Phillip J. Eby) Date: Sun, 04 May 2008 14:13:50 -0400 Subject: [Distutils] Script Files, Prefix, and Uninstallation In-Reply-To: References: <20080504175123.D09A93A4036@sparrow.telecommunity.com> Message-ID: <20080504181332.810323A4036@sparrow.telecommunity.com> At 08:56 PM 5/4/2008 +0300, natan yellin wrote: >On Sun, May 4, 2008 at 8:51 PM, Phillip J. Eby ><pje at telecommunity.com> wrote: >At 11:04 AM 5/4/2008 +0300, natan yellin wrote: >Hello, >I'm relatively new to python, and I have a few questions related to distutils. > >1) If I attempt to install script files without a .py extension, >distutils installs them twice- once with a .py extension and once >without. Is there a way to work around that? > > >I've never seen the behavior you're describing. You should probably >post your setup.py for us to see what you're doing. > >I've attached it. By "post", I mean posting it to the distutils-sig. I don't do private tech support - especially not for the distutils. >2) Is there a way to change the default install prefix from /usr to >/usr/local? > > >You can change that systemwide by creating the appropriate config >file. Please see the configuration file section of the "Installing >Python Modules" manual. > >Is there any way to change it within the script? It makes more sense >to install my particular app into /usr/local than /usr. It can be changed in lots of places, including the script or setup.cfg. Please see the manual. From aantny at gmail.com Sun May 4 20:24:33 2008 From: aantny at gmail.com (natan yellin) Date: Sun, 4 May 2008 21:24:33 +0300 Subject: [Distutils] Script Files, Prefix, and Uninstallation In-Reply-To: <20080504181332.810323A4036@sparrow.telecommunity.com> References: <20080504175123.D09A93A4036@sparrow.telecommunity.com> <20080504181332.810323A4036@sparrow.telecommunity.com> Message-ID: On Sun, May 4, 2008 at 9:13 PM, Phillip J. Eby wrote: > At 08:56 PM 5/4/2008 +0300, natan yellin wrote: > > > On Sun, May 4, 2008 at 8:51 PM, Phillip J. Eby < > pje at telecommunity.com>pje at telecommunity.com> wrote: > > At 11:04 AM 5/4/2008 +0300, natan yellin wrote: > > Hello, > > I'm relatively new to python, and I have a few questions related to > > distutils. > > > > 1) If I attempt to install script files without a .py extension, > > distutils installs them twice- once with a .py extension and once without. > > Is there a way to work around that? > > > > > > I've never seen the behavior you're describing. You should probably > > post your setup.py for us to see what you're doing. > > > > I've attached it. > > > > By "post", I mean posting it to the distutils-sig. I don't do private > tech support - especially not for the distutils. Sorry. I forgot to change the address. > > > > 2) Is there a way to change the default install prefix from /usr to > > /usr/local? > > > > > > You can change that systemwide by creating the appropriate config file. > > Please see the configuration file section of the "Installing Python > > Modules" manual. > > > > Is there any way to change it within the script? It makes more sense to > > install my particular app into /usr/local than /usr. > > > > It can be changed in lots of places, including the script or setup.cfg. > Please see the manual. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ziade.tarek at gmail.com Wed May 7 09:25:07 2008 From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Wed, 7 May 2008 09:25:07 +0200 Subject: [Distutils] #1858, looking for a reviewer Message-ID: <94bdd2610805070025s5899ea26ke5fac80c5f70aab9@mail.gmail.com> Hi, The register and upload commands have a --repository option that allows to use them with any server. You can register and upload a package to any server that has the right set of web services. They also work with a configuration file called .pypirc Unfortunately there is no inline option to define the username/password. This has to be defined in .pypirc. But this file does not allow having different sets of username/password, so in reality it is not possible to play with multiple servers. #1858 provides a patch for this [0] I have submitted it in January, after some discussion in catalog-sig and distutils-sig, that led to a proposal [1] I am looking for a final reviewer, to decide if the new .pypirc is considered suitable, and maybe have it integrated in the 2.6. This new format will be used in the Plone community to interact with plone.org and the cheeseshop [2], (with a third party package at this time, that implements the patch) Regards Tarek [0] http://bugs.python.org/issue1858 [1] http://wiki.python.org/moin/EnhancedPyPI [2] http://tarekziade.wordpress.com/2008/05/06/plone-paris-sprint-wrapup-3-newploneorg-collectivedist-released/ -- Tarek Ziad? | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/ From bignose+hates-spam at benfinney.id.au Wed May 7 14:14:24 2008 From: bignose+hates-spam at benfinney.id.au (Ben Finney) Date: Wed, 07 May 2008 22:14:24 +1000 Subject: [Distutils] desirability of multiple, divergent Python instances References: <1208019508.3212.169.camel@portableevil.develix.com> <20080412175146.51B3E3A409E@sparrow.telecommunity.com> <1208028604.3212.193.camel@portableevil.develix.com> <20080412215326.B6CB03A406A@sparrow.telecommunity.com> <1208039212.3212.214.camel@portableevil.develix.com> <20080412225006.GN8360@phare.normalesup.org> <23BDD366-BB0D-488E-B9CE-3C4A55573E09@python.org> <480164B4.5080901@pangalactic.us> <1006AECE-3273-418A-A804-228177D4DCBB@python.org> <480223E9.5040902@pangalactic.us> <20080413152925.GF24381@phare.normalesup.org> <4802B3A6.5020606@canterbury.ac.nz> <87od8dtacu.fsf_-_@benfinney.id.au> <4802E4BD.4090408@pangalactic.us> <87zlrr4qpw.fsf@benfinney.id.au> Message-ID: <87tzhab9b3.fsf@benfinney.id.au> Ben Finney writes: > Stephen Waterbury writes: > > > My main motivation in proposing it is to give the user complete > > control over the Python environment that is in their path -- which > > is not easy to do on Debian/Ubuntu at the moment > > This is a laudable goal. It is met, for just about every other > user-configurable application, by allowing user-specific *overrides* > to the defaults to be set in configuration files. I'm glad to see PEP 370 has been approved (2008-05-06) for Python 2.6 and Python 3.0. Abstract This PEP proposes a new a per user site-packages directory to allow users the local installation of Python packages in their home directory. This addresses the issue following exactly the principle I described above, so I heartily approve. -- \ "Experience is that marvelous thing that enables you to | `\ recognize a mistake when you make it again." -- Franklin P. | _o__) Jones | Ben Finney From ben at benfinney.id.au Wed May 7 15:20:12 2008 From: ben at benfinney.id.au (Ben Finney) Date: Wed, 07 May 2008 23:20:12 +1000 Subject: [Distutils] Puppet blog: Ruby has a distribution problem Message-ID: <877ie6b69f.fsf@benfinney.id.au> Howdy all, An interesting blog post from Luke Kanies that sparks an even more interesting discussion in the comments. There seems to be a split between those developers who write software that is expected to run in one place and those who write software that is expected to run in many places. If you, as a developer, know that your software will really only be installed at a single customer [...], then your life is drastically easier -- you don't usually have to worry about cross-platform issues, and you don't have to worry about different users having different needs, because you only have one user. Obviously there's no inherent problem with having the simpler life of a developer with only one user, but it seems to me that the Ruby community is, as a group, largely adopting that perspective as the default. This is worrying to me, because I'm building an application that I expect to be installed in thousands of locations (in fact, it's probably already installed in thousands of locations). I'd like to take as much advantage of existing Ruby code as possible, but it's not exactly easy. It's about Ruby's current state of package distribution, but has many points that will be familiar to critics of distutils, setuptools, and cheese shop, or to readers of this forum in the last couple of weeks. -- \ ?I cannot conceive that anybody will require multiplications | `\ at the rate of 40,000 or even 4,000 per hour ...? ?F. H. | _o__) Wales, 1936 | Ben Finney From jeff at taupro.com Thu May 8 10:40:25 2008 From: jeff at taupro.com (Jeff Rush) Date: Thu, 08 May 2008 03:40:25 -0500 Subject: [Distutils] Issues Tracker for Setuptools Message-ID: <4822BC79.30802@taupro.com> We now have a specific issues tracker for setuptools at: http://bugs.python.org/setuptools/ and setuptools at bugs.python.org (for email issue postings) using the Roundup tracker software also used for Python bug tracking. Note that the trailing slash is NOT optional. For now the tracker echoes bug reports onto the distutils list, for community awareness. If this turns out to be a problem, I'll create a separate distutils-bugs list but wanted to avoid having folks sign up for "yet-another-list" if I would avoid it. -Jeff From setuptools at bugs.python.org Thu May 8 11:03:13 2008 From: setuptools at bugs.python.org (Jeroen Ruigrok van der Werven) Date: Thu, 08 May 2008 09:03:13 +0000 Subject: [Distutils] [issue1] amd64 eggs are called x86_64 Message-ID: <1210237392.6.0.43027729404.issue1@psf.upfronthosting.co.za> New submission from Jeroen Ruigrok van der Werven : Currently eggs created for amd64 platforms are called x86_64 in the egg filename. AMD renamed x86_64 to amd64 and asked people to follow suit. Also Python uses the amd64 nomenclature: http://mail.python.org/pipermail/python-bugs-list/2006-December/036400.html and http://mail.python.org/pipermail/python-dev/2008-May/079056.html As such, to limit end-user confusion eggs should be named amd64 as well instead of x86_64. ---------- messages: 1 nosy: asmodai priority: bug status: unread title: amd64 eggs are called x86_64 _______________________________________________ Setuptools tracker _______________________________________________ From setuptools at bugs.python.org Thu May 8 11:08:37 2008 From: setuptools at bugs.python.org (Jeroen Ruigrok van der Werven) Date: Thu, 08 May 2008 09:08:37 +0000 Subject: [Distutils] [issue2] easy_install broken on 64 bits Windows Message-ID: <1210237716.84.0.293606313025.issue2@psf.upfronthosting.co.za> New submission from Jeroen Ruigrok van der Werven : As I reported in http://mail.python.org/pipermail/distutils-sig/2008-April/009398.html easy_install on a 64 bits Python on a 64 bits Windows is broken in that it gives the following error: Cannot find Python executable C:\Python25\python.exe I believe that due to cli.exe and gui.exe (built from launcher.c) being 32-bits executables they are trying to use 32-bit specific calls which fail on a 64 bits Windows. As Mark Hammond said in http://mail.python.org/pipermail/distutils-sig/2008-May/009462.html: "I suspect that the issue is that a 32bit cli.exe or gui.exe is attempting to LoadLibrary a 64bit executable and failing (specifically, loadable_exe() in launcher.c)" ---------- messages: 2 nosy: asmodai priority: urgent status: unread title: easy_install broken on 64 bits Windows _______________________________________________ Setuptools tracker _______________________________________________ From setuptools at bugs.python.org Thu May 8 11:14:16 2008 From: setuptools at bugs.python.org (Jeroen Ruigrok van der Werven) Date: Thu, 08 May 2008 09:14:16 +0000 Subject: [Distutils] [issue3] eggs on Windows do not differentiate between 32- or 64-bits Message-ID: <1210238056.55.0.572575317215.issue3@psf.upfronthosting.co.za> New submission from Jeroen Ruigrok van der Werven : As I explained in http://mail.python.org/pipermail/distutils-sig/2008-April/009398.html eggs created on either a 32- or 64-bits Windows call the resulting file only a win32 egg. For pure Python modules this is not an issue. However, when using speedups or other code that needs to be natively compiled (C source code for example) you generate specific binaries for either 32- or 64-bits. We already differentiate between these versions on Unix and as such we should do the same on Windows. Something like module-1.0-py2.5-win32-i386.egg or module-1.0-py2.5-win32-amd64.egg. ---------- messages: 3 nosy: asmodai priority: urgent status: unread title: eggs on Windows do not differentiate between 32- or 64-bits _______________________________________________ Setuptools tracker _______________________________________________ From asmodai at in-nomine.org Thu May 8 11:15:07 2008 From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven) Date: Thu, 8 May 2008 11:15:07 +0200 Subject: [Distutils] Issues Tracker for Setuptools In-Reply-To: <4822BC79.30802@taupro.com> References: <4822BC79.30802@taupro.com> Message-ID: <20080508091507.GA1016@nexus.in-nomine.org> -On [20080508 10:37], Jeff Rush (jeff at taupro.com) wrote: >We now have a specific issues tracker for setuptools at: > > http://bugs.python.org/setuptools/ Thanks Jeff, I've taken the liberty to seed it with 3 issues already. ^^ -- Jeroen Ruigrok van der Werven / asmodai ????? ?????? ??? ?? ?????? http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B If Winter comes, can Spring be far behind..? From mhammond at skippinet.com.au Thu May 8 14:21:11 2008 From: mhammond at skippinet.com.au (Mark Hammond) Date: Thu, 8 May 2008 22:21:11 +1000 Subject: [Distutils] [issue1] amd64 eggs are called x86_64 In-Reply-To: <1210237392.6.0.43027729404.issue1@psf.upfronthosting.co.za> References: <1210237392.6.0.43027729404.issue1@psf.upfronthosting.co.za> Message-ID: <015501c8b106$051ff640$0f5fe2c0$@com.au> > Currently eggs created for amd64 platforms are called x86_64 in the egg > filename. AMD renamed x86_64 to amd64 and asked people to follow suit. > Also Python uses the amd64 nomenclature: > http://mail.python.org/pipermail/python-bugs-list/2006- > December/036400.html and > http://mail.python.org/pipermail/python-dev/2008-May/079056.html > > As such, to limit end-user confusion eggs should be named amd64 as well > instead of x86_64. Note that "win-" should probably be in the filename too. eg, the py 2.6 trunk building pywin32 will create a filename 'pywin32-210.9.win-amd64-py2.6.exe' Cheers, Mark From setuptools at bugs.python.org Thu May 8 15:06:45 2008 From: setuptools at bugs.python.org (Jeff Kowalczyk) Date: Thu, 08 May 2008 13:06:45 +0000 Subject: [Distutils] [issue4] subversion 1.5 working copy causes problem in entries_finder: NameError: global name 'log' is not defined In-Reply-To: <1210252005.03.0.220258290924.issue4@psf.upfronthosting.co.za> Message-ID: <1210252005.03.0.220258290924.issue4@psf.upfronthosting.co.za> New submission from Jeff Kowalczyk : When I upgraded to subversion-1.5, working copies using various combinations of virtualenv, zc.buildout, setuptools all stopped working with errors similar to the following: python: /opt/python24/python/bin/python virtualenv (svn trunk) activated working copy: svn://svn.zope.org/repos/main/z3c.formdemo/trunk virtualenv python bootstrap.py, .bin/buildout try to upgrade setuptools to dev copy per PJE mailing list post: (formdemo) /software/z3c/formdemo $ easy_install setuptools==dev06 Searching for setuptools==dev06 Reading http://pypi.python.org/simple/setuptools/ Best match: setuptools dev06 Downloading http://svn.python.org/projects/sandbox/branches/setuptools-0.6/#egg=setuptools-dev06 Doing subversion checkout from http://svn.python.org/projects/sandbox/branches/setuptools-0.6/ to /tmp/easy_install-MKC07e/setuptools-0.6 Processing setuptools-0.6 Running setup.py -q bdist_egg --dist-dir /tmp/easy_install-MKC07e/setuptools-0.6/egg-dist-tmp-izAnB2 unrecognized .svn/entries format; skipping . Traceback (most recent call last): File "/software/z3c/formdemo/bin/easy_install", line 7, in ? sys.exit( File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/command/easy_install.py", line 1671, in main with_ei_usage(lambda: File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/command/easy_install.py", line 1659, in with_ei_usage return f() File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/command/easy_install.py", line 1675, in distclass=DistributionWithoutHelpCommands, **kw File "/opt/python24/./python/lib/python2.4/distutils/core.py", line 149, in setup dist.run_commands() File "/opt/python24/./python/lib/python2.4/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/opt/python24/./python/lib/python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/command/easy_install.py", line 211, in run self.easy_install(spec, not self.no_deps) File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/command/easy_install.py", line 446, in easy_install return self.install_item(spec, dist.location, tmpdir, deps) File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/command/easy_install.py", line 476, in install_item dists = self.install_eggs(spec, download, tmpdir) File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/command/easy_install.py", line 655, in install_eggs return self.build_and_install(setup_script, setup_base) File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/command/easy_install.py", line 930, in build_and_install self.run_setup(setup_script, setup_base, args) File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/command/easy_install.py", line 919, in run_setup run_setup(setup_script, args) File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/sandbox.py", line 26, in run_setup DirectorySandbox(setup_dir).run( File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/sandbox.py", line 63, in run return func() File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/sandbox.py", line 29, in {'__file__':setup_script, '__name__':'__main__'} File "setup.py", line 94, in ? 'zope.traversing', File "/opt/python24/./python/lib/python2.4/distutils/core.py", line 149, in setup dist.run_commands() File "/opt/python24/./python/lib/python2.4/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/opt/python24/./python/lib/python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/command/bdist_egg.py", line 167, in run self.run_command("egg_info") File "/opt/python24/./python/lib/python2.4/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/opt/python24/./python/lib/python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/command/egg_info.py", line 171, in run self.find_sources() File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/command/egg_info.py", line 252, in find_sources mm.run() File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/command/egg_info.py", line 306, in run self.add_defaults() File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/command/egg_info.py", line 333, in add_defaults rcfiles = list(walk_revctrl()) File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/command/sdist.py", line 45, in walk_revctrl for item in ep.load()(dirname): File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/command/sdist.py", line 52, in _default_revctrl for path in finder(dirname,path): File "/software/z3c/formdemo/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/setuptools/command/sdist.py", line 98, in entries_finder log.warn("unrecognized .svn/entries format in %s", dirname) NameError: global name 'log' is not defined Apologies for the lack of additional detail here, I've reverted to subversion-1.4 and recreated all working copies. This was experienced on all working copies of various projects after upgrading to subversion-1.5, and was fully fixed when reverting to subversion-1.4. ---------- messages: 5 nosy: jfkw priority: bug status: unread title: subversion 1.5 working copy causes problem in entries_finder: NameError: global name 'log' is not defined _______________________________________________ Setuptools tracker _______________________________________________ From zooko at zooko.com Thu May 8 15:14:31 2008 From: zooko at zooko.com (zooko) Date: Thu, 8 May 2008 07:14:31 -0600 Subject: [Distutils] Issues Tracker for Setuptools In-Reply-To: <4822BC79.30802@taupro.com> References: <4822BC79.30802@taupro.com> Message-ID: <72178D03-FF14-4395-A232-E3B0BD088518@zooko.com> On May 8, 2008, at 2:40 AM, Jeff Rush wrote: > We now have a specific issues tracker for setuptools at: > >> http://bugs.python.org/setuptools/ Thank you very much, Jeff! I've added a note to the front page of my setuptools issue tracker asking people to use the official one insteda: http://allmydata.org/trac/setuptools Regards, Zooko From setuptools at bugs.python.org Thu May 8 15:29:49 2008 From: setuptools at bugs.python.org (Jeroen Ruigrok van der Werven) Date: Thu, 08 May 2008 13:29:49 +0000 Subject: [Distutils] [issue5] setuptools uses deprecated module md5 In-Reply-To: <1210253387.92.0.86209870245.issue5@psf.upfronthosting.co.za> Message-ID: <1210253387.92.0.86209870245.issue5@psf.upfronthosting.co.za> New submission from Jeroen Ruigrok van der Werven : Setuptools currently uses the module md5, which will be deprecated after 2.6 and 2.6 warns about this use. Find attached a patch I emailed to Phillip a while ago but still did not get applied. ---------- messages: 6 nosy: asmodai priority: bug status: unread title: setuptools uses deprecated module md5 _______________________________________________ Setuptools tracker _______________________________________________ From asmodai at in-nomine.org Thu May 8 15:30:10 2008 From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven) Date: Thu, 8 May 2008 15:30:10 +0200 Subject: [Distutils] Issues Tracker for Setuptools In-Reply-To: <4822BC79.30802@taupro.com> References: <4822BC79.30802@taupro.com> Message-ID: <20080508133010.GA64342@nexus.in-nomine.org> -On [20080508 10:37], Jeff Rush (jeff at taupro.com) wrote: >We now have a specific issues tracker for setuptools at: > > http://bugs.python.org/setuptools/ Can we get a patch keyword? -- Jeroen Ruigrok van der Werven / asmodai ????? ?????? ??? ?? ?????? http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B If Winter comes, can Spring be far behind..? From p.f.moore at gmail.com Fri May 9 00:45:10 2008 From: p.f.moore at gmail.com (Paul Moore) Date: Thu, 8 May 2008 23:45:10 +0100 Subject: [Distutils] Issues Tracker for Setuptools In-Reply-To: <4822BC79.30802@taupro.com> References: <4822BC79.30802@taupro.com> Message-ID: <79990c6b0805081545s17b42b91ua7a0f5adbe13e5a4@mail.gmail.com> 2008/5/8 Jeff Rush : > Note that the trailing slash is NOT optional. For now the tracker echoes > bug reports onto the distutils list, for community awareness. If this turns > out to be a problem, I'll create a separate distutils-bugs list but wanted > to avoid having folks sign up for "yet-another-list" if I would avoid it. Please set up a new list. I am not interested enough in setuptools (as opposed to distutils in general) to want to see all the bug reports. Paul. From setuptools at bugs.python.org Fri May 9 05:14:49 2008 From: setuptools at bugs.python.org (Peter Fein) Date: Fri, 09 May 2008 03:14:49 +0000 Subject: [Distutils] [issue6] all files installed +x In-Reply-To: <1210302889.74.0.33571324181.issue6@psf.upfronthosting.co.za> Message-ID: <1210302889.74.0.33571324181.issue6@psf.upfronthosting.co.za> New submission from Peter Fein : Setuptools installs all files with mode +x (executable), overriding any permissions specified in the original archive. The consensus on the distutils mailing list is that doing so is incorrect, and potentially dangerous. It also breaks nosetests. No final determination was received from PJE. For extensive discussion, see: http://nabble.decenturl.com/setuptools-nose-chmod- bug ---------- messages: 7 nosy: pfein priority: bug status: unread title: all files installed +x _______________________________________________ Setuptools tracker _______________________________________________ From greg.ewing at canterbury.ac.nz Fri May 9 05:29:33 2008 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Fri, 09 May 2008 15:29:33 +1200 Subject: [Distutils] [issue6] all files installed +x In-Reply-To: <1210302889.74.0.33571324181.issue6@psf.upfronthosting.co.za> References: <1210302889.74.0.33571324181.issue6@psf.upfronthosting.co.za> Message-ID: <4823C51D.3080503@canterbury.ac.nz> Peter Fein wrote: > Setuptools installs all files with mode +x (executable), overriding any > permissions specified in the original archive. ALL files? Literally? If that's true, then on Unix this is astonishingly wrong and definitely needs to be fixed. -- Greg From pfein at pobox.com Fri May 9 06:01:08 2008 From: pfein at pobox.com (Pete) Date: Fri, 9 May 2008 00:01:08 -0400 Subject: [Distutils] [issue6] all files installed +x In-Reply-To: <4823C51D.3080503@canterbury.ac.nz> References: <1210302889.74.0.33571324181.issue6@psf.upfronthosting.co.za> <4823C51D.3080503@canterbury.ac.nz> Message-ID: On May 8, 2008, at 11:29 PM, Greg Ewing wrote: > Peter Fein wrote: > >> Setuptools installs all files with mode +x (executable), overriding >> any permissions specified in the original archive. > > ALL files? Literally? All .py/.pyc files, yes. > If that's true, then on Unix this is astonishingly > wrong and definitely needs to be fixed. I believe I called it "broken and dangerous". Full discussion at: http://nabble.decenturl.com/setuptools-nose-chmod-bug From setuptools at bugs.python.org Fri May 9 09:34:22 2008 From: setuptools at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Fri, 09 May 2008 07:34:22 +0000 Subject: [Distutils] [issue7] allow-host will not allow local files In-Reply-To: <1210318462.56.0.582926548978.issue7@psf.upfronthosting.co.za> Message-ID: <1210318462.56.0.582926548978.issue7@psf.upfronthosting.co.za> New submission from Tarek Ziad? : while playing with the allow-host options in setuptools, I have noticed that it is restricted to URLs because url_ok() uses urlparse over the regular expressions that are provided This means that it is not possible to allow local folders to be visited since a "file://*" expression for example, will lead to an empty string: >>> import urlparse >>> urlparse.urlparse('file:///tmp/my/local/file.tgz')[1] '' This will make some links blocked and impossible to add as authorized resource: ... Link to file:///tmp/tmpE-LbUpbuildouttests/setuptools/ ***BLOCKED*** by --allow-hosts ... I have attached a patch to fix this. ---------- files: distutils.allow-hosts.patch messages: 8 nosy: tarek priority: bug status: unread title: allow-host will not allow local files Added file: http://bugs.python.org/setuptools/file2/distutils.allow-hosts.patch _______________________________________________ Setuptools tracker _______________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: distutils.allow-hosts.patch Type: application/octet-stream Size: 1281 bytes Desc: not available URL: From setuptools at bugs.python.org Fri May 9 23:49:53 2008 From: setuptools at bugs.python.org (Philip Jenvey) Date: Fri, 09 May 2008 21:49:53 +0000 Subject: [Distutils] [issue8] pkg_resources.declare_namespace inconsistency vs pkgutil.extend_path In-Reply-To: <1210369793.62.0.348170565627.issue8@psf.upfronthosting.co.za> Message-ID: <1210369793.62.0.348170565627.issue8@psf.upfronthosting.co.za> New submission from Philip Jenvey : Paste uses pkg_resources.declare_namespace: >>> import sys >>> import paste >>> paste.__path__ ['/usr/local/lib/python2.5/site-packages/Paste-1.6-py2.5.egg/paste', '/usr/local/lib/python2.5/site-packages/PasteDeploy-1.3.1-py2.5.egg/ paste', '/usr/local/lib/python2.5/site-packages/PasteScript-1.6.2- py2.5.egg/paste'] >>> del sys.modules['paste'] >>> import paste >>> paste.__path__ ['/usr/local/lib/python2.5/site-packages/Paste-1.6-py2.5.egg/paste'] Whereas pkgutil.extend_path does the right thing and restores paste.__path__ to contain the 3 paths ---------- keyword: pkg_resources messages: 10 nosy: pjenvey priority: bug status: unread title: pkg_resources.declare_namespace inconsistency vs pkgutil.extend_path _______________________________________________ Setuptools tracker _______________________________________________ From setuptools at bugs.python.org Sat May 10 00:09:17 2008 From: setuptools at bugs.python.org (Philip Jenvey) Date: Fri, 09 May 2008 22:09:17 +0000 Subject: [Distutils] [issue9] [PATCH] native_libs.txt created in .egg-info/; should only be in EGG-INFO/ In-Reply-To: <1210370955.44.0.232597258771.issue9@psf.upfronthosting.co.za> Message-ID: <1210370955.44.0.232597258771.issue9@psf.upfronthosting.co.za> New submission from Philip Jenvey : native_libs.txt shouldn't be created in projects' .egg-info/ dirs. When one is created there, it will be listed in SOURCES.txt. Depending on the environment the egg is built on, native lib extensions may be disabled at egg build time (such as due to the lack of a C compiler; in particular, simplejson and Genshi do this) -- which can cause native_libs.txt to be empty. When its empty its pruned from the .egg-info dir. Then when the entries in SOURCES.txt are copied to the final egg directory, setuptools breaks when attempting to copy a non existent native_libs.txt from the .egg-info/ dir. The solution is to only generate native_libs.txt in the finished egg's EGG-INFO directory. Attached is a patch to only generate native_libs.txt in the final EGG-INFO/ dir and have the egg_info command correct the problem by always pruning native_libs.txt from the .egg-info/ dir. It also disables the failing tests on Jython (which are for experimental functionality that isn't actually used anyway) For the orig. discussion see: http://mail.python.org/pipermail/distutils- sig/2008-February/008805.html ---------- messages: 11 nosy: pjenvey priority: bug status: unread title: [PATCH] native_libs.txt created in .egg-info/; should only be in EGG-INFO/ _______________________________________________ Setuptools tracker _______________________________________________ From setuptools at bugs.python.org Sat May 10 00:13:49 2008 From: setuptools at bugs.python.org (Philip Jenvey) Date: Fri, 09 May 2008 22:13:49 +0000 Subject: [Distutils] [issue10] [PATCH] Immediately close all file handles In-Reply-To: <1210371228.69.0.792091594164.issue10@psf.upfronthosting.co.za> Message-ID: <1210371228.69.0.792091594164.issue10@psf.upfronthosting.co.za> New submission from Philip Jenvey : I'm being pessimistic here and ensuring setuptools closes all files immediately when done with them, in particular for Python VMs that don't use reference counting GC. Those VMs may not GC/close those files until later, and open file handles are particularly bad on Windows (you can't delete a file that's in use). This is of low priority ---------- files: close_fp-r60849.diff messages: 12 nosy: pjenvey priority: wish status: unread title: [PATCH] Immediately close all file handles Added file: http://bugs.python.org/setuptools/file4/close_fp-r60849.diff _______________________________________________ Setuptools tracker _______________________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: close_fp-r60849.diff URL: From lists at informa.tiker.net Mon May 12 18:16:19 2008 From: lists at informa.tiker.net (Andreas =?utf-8?q?Kl=C3=B6ckner?=) Date: Mon, 12 May 2008 12:16:19 -0400 Subject: [Distutils] Bad tracebacks from packages installed using setuptools Message-ID: <200805121216.20865.lists@informa.tiker.net> Hi there, I'm getting tracebacks like this from a package (pymbolic in this case--available from PyPI) installed using setuptools. 8< ----------------------------------------------------------------------------- File "build/bdist.linux-x86_64/egg/pymbolic/primitives.py", line 150, in __str__ File "/usr/lib/python2.5/site-packages/PIL/__init__.py", line 17, in __call__ File "build/bdist.linux-x86_64/egg/pymbolic/mapper/stringifier.py", line 75, in map_product File "build/bdist.linux-x86_64/egg/pymbolic/mapper/stringifier.py", line 75, in File "/usr/lib/python2.5/site-packages/PIL/__init__.py", line 58, in rec File "build/bdist.linux-x86_64/egg/pymbolic/mapper/stringifier.py", line 23, in handle_unsupported_expression 8< ----------------------------------------------------------------------------- At least two things are bad here: - Some source files refer to their relative location in the build directory of their *own* package. Unsurprisingly, this is not found when an exception occurs in user code that does not live in the package's base directory. - Whenever a file name is __init__.py, the PIL __init__.py gets picked up instead of the corect file name. (nothing uses PIL in what generated the above) What can I do to fix this? (setuptools 0.6c8 on 2.5) Thanks Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From pje at telecommunity.com Mon May 12 19:08:39 2008 From: pje at telecommunity.com (Phillip J. Eby) Date: Mon, 12 May 2008 13:08:39 -0400 Subject: [Distutils] Bad tracebacks from packages installed using setuptools In-Reply-To: <200805121216.20865.lists@informa.tiker.net> References: <200805121216.20865.lists@informa.tiker.net> Message-ID: <20080512170817.637613A40AE@sparrow.telecommunity.com> At 12:16 PM 5/12/2008 -0400, Andreas Kl??ckner wrote: >At least two things are bad here: > >- Some source files refer to their relative location in the build >directory of >their *own* package. Unsurprisingly, this is not found when an exception >occurs in user code that does not live in the package's base directory. > >- Whenever a file name is __init__.py, the PIL __init__.py gets picked up >instead of the corect file name. (nothing uses PIL in what generated the >above) > >What can I do to fix this? (setuptools 0.6c8 on 2.5) The first can only be fixed by installing files unzipped; the second I've never seen before and have no idea about. From zooko at zooko.com Mon May 12 19:23:00 2008 From: zooko at zooko.com (zooko) Date: Mon, 12 May 2008 11:23:00 -0600 Subject: [Distutils] Bad tracebacks from packages installed using setuptools In-Reply-To: <200805121216.20865.lists@informa.tiker.net> References: <200805121216.20865.lists@informa.tiker.net> Message-ID: <77B5938A-1FE6-48BE-83F3-0DCD01FAF996@zooko.com> On May 12, 2008, at 10:16 AM, Andreas Kl?ckner wrote: > - Some source files refer to their relative location in the build > directory of > their *own* package. Unsurprisingly, this is not found when an > exception > occurs in user code that does not live in the package's base > directory. http://allmydata.org/trac/setuptools/ticket/4 # (when considering whether to zip, err on the side of safety rather than performance) > - Whenever a file name is __init__.py, the PIL __init__.py gets > picked up > instead of the corect file name. (nothing uses PIL in what > generated the > above) http://allmydata.org/trac/setuptools/ticket/3 # (setuptools invokes system-wide setuptools instead of local setuptools, possibly due to interference from nevow) Both of these tickets (as all tickets in http://allmydata.org/trac/ setuptools ) ought to be migrated to the new, official setuptools issue tracker at http://bugs.python.org/setuptools/ . Regards, Zooko From lists at informa.tiker.net Mon May 12 19:27:25 2008 From: lists at informa.tiker.net (Andreas =?iso-8859-1?q?Kl=F6ckner?=) Date: Mon, 12 May 2008 13:27:25 -0400 Subject: [Distutils] Bad tracebacks from packages installed using setuptools In-Reply-To: <20080512170817.637613A40AE@sparrow.telecommunity.com> References: <200805121216.20865.lists@informa.tiker.net> <20080512170817.637613A40AE@sparrow.telecommunity.com> Message-ID: <200805121327.26199.lists@informa.tiker.net> On Montag 12 Mai 2008, Phillip J. Eby wrote: > At 12:16 PM 5/12/2008 -0400, Andreas Kl??ckner wrote: > >- Some source files refer to their relative location in the build > >directory of > >their *own* package. Unsurprisingly, this is not found when an exception > >occurs in user code that does not live in the package's base directory. > > > >- Whenever a file name is __init__.py, the PIL __init__.py gets picked up > >instead of the corect file name. (nothing uses PIL in what generated the > >above) > > > >What can I do to fix this? (setuptools 0.6c8 on 2.5) > > The first can only be fixed by installing files unzipped; I assume that this depends on core Python getting smarter about how it fetches these lines. Are there plans to address this? > the second > I've never seen before and have no idea about. Hmm, ok. I'll try and investigate at some point. Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From andrewfr_ice at yahoo.com Wed May 14 18:15:14 2008 From: andrewfr_ice at yahoo.com (Andrew Francis) Date: Wed, 14 May 2008 09:15:14 -0700 (PDT) Subject: [Distutils] Problem with Setuptools on Ubuntu 8.0.4 Message-ID: <277849.10594.qm@web34202.mail.mud.yahoo.com> Hi: I have the following problem with Ubuntu 8.04 Desktop and Xandros on the EEE ASUS. I am trying to install PyAMF-0.3.1 python setup.py install Traceback (most recent call last): File "setup.py", line 6, in use_setuptools() File "/home/afrancis/Public/PyAMF-0.3.1/ez_setup.py", line 91, in use_setuptools import setuptools; setuptools.bootstrap_install_from = egg zipimport.ZipImportError: can't decompress data; zlib not available Any help solving this would be appreciated. Cheers, Andrew From pje at telecommunity.com Wed May 14 18:38:39 2008 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed, 14 May 2008 12:38:39 -0400 Subject: [Distutils] Problem with Setuptools on Ubuntu 8.0.4 In-Reply-To: <277849.10594.qm@web34202.mail.mud.yahoo.com> References: <277849.10594.qm@web34202.mail.mud.yahoo.com> Message-ID: <20080514163824.0E14B3A4061@sparrow.telecommunity.com> At 09:15 AM 5/14/2008 -0700, Andrew Francis wrote: >Hi: > >I have the following problem with Ubuntu 8.04 Desktop >and Xandros on the EEE ASUS. I am trying to install >PyAMF-0.3.1 > >python setup.py install > >Traceback (most recent call last): > File "setup.py", line 6, in > use_setuptools() > File >"/home/afrancis/Public/PyAMF-0.3.1/ez_setup.py", line >91, in use_setuptools > import setuptools; >setuptools.bootstrap_install_from = egg >zipimport.ZipImportError: can't decompress data; zlib >not available Looks like you're missing python-zlib or some such Ubuntu package. Dunno what it'd actually be called, that's just a guess at the name. From andrewfr_ice at yahoo.com Wed May 14 21:52:01 2008 From: andrewfr_ice at yahoo.com (Andrew Francis) Date: Wed, 14 May 2008 12:52:01 -0700 (PDT) Subject: [Distutils] Problem with Setuptools on Ubuntu 8.0.4 In-Reply-To: <20080514163824.0E14B3A4061@sparrow.telecommunity.com> Message-ID: <131808.62185.qm@web34207.mail.mud.yahoo.com> Hello: > Looks like you're missing python-zlib or some such > Ubuntu package. Dunno what it'd actually be called, >that's just a guess at the name. I don't see a python-zlib in the Hardy distribution. Debian seems to have a python-zlib package. So what is the easiest way of adapting that package for Ubuntu? Cheers, Andrew From me at lbruno.org Thu May 15 11:05:32 2008 From: me at lbruno.org (Luis Bruno) Date: Thu, 15 May 2008 10:05:32 +0100 Subject: [Distutils] Problem with Setuptools on Ubuntu 8.0.4 In-Reply-To: <131808.62185.qm@web34207.mail.mud.yahoo.com> References: <131808.62185.qm@web34207.mail.mud.yahoo.com> Message-ID: <482BFCDC.7010507@lbruno.org> Andrew Francis escreveu: > I don't see a python-zlib in the Hardy distribution. lithium> python Python 2.5.2 (r252:60911, Apr 21 2008, 11:17:30) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import zlib >>> zlib >>> lithium> dpkg -S /usr/lib/python2.5/lib-dynload/zlib.so python2.5-minimal: /usr/lib/python2.5/lib-dynload/zlib.so IIRC, python2.5-minimal is part of the default installation. Reinstall that package and find out what caused that file to go away. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From amk at amk.ca Thu May 15 22:33:53 2008 From: amk at amk.ca (A.M. Kuchling) Date: Thu, 15 May 2008 16:33:53 -0400 Subject: [Distutils] Distutils & configparser rename Message-ID: <20080515203353.GA24080@amk-desktop.matrixgroup.net> Python 2.6 renames the ConfigParser module to be configparser. Distutils imports ConfigParser in various places. I just made a commit updating the import in one places, and then noticed that part of commit r63248, which made the same change, was reverted in order to preserve backward-compatibility. Instead, the default path will include lib-old again to keep the old module name available. I suggest dropping that goal, though. We've preserved compatibility but I'm not aware that anyone uses the Python 2.x Distutils with earlier versions of Python. In particular: * There's no standalone distutils package on PyPI, nor can I find such a package with a general web search. Am I missing it? * I do not see users advising other users to use a later version of Distutils to fix their problems. Is anyone actually benefiting from the effort of maintaining backward compatibility? --amk From zooko at zooko.com Fri May 16 00:01:55 2008 From: zooko at zooko.com (zooko) Date: Thu, 15 May 2008 16:01:55 -0600 Subject: [Distutils] how do you express a platform-specific dependency? Message-ID: <454C9211-F9E8-4346-A453-4175A4813E77@zooko.com> Folks: Twisted requires pywin32 if it is running on Windows. How can the twisted package metadata [1], which is produced by the twisted setup.py [2], specify this dependency so that if you easy_install Twisted on Windows you'll get pywin32 as well, but if you easy_install Twisted on another platform you won't? Regards, Zooko [1] http://pypi.python.org/pypi/Twisted [2] http://twistedmatrix.com/trac/browser/trunk/setup.py?rev=23010#L76 From zooko at zooko.com Fri May 16 00:15:17 2008 From: zooko at zooko.com (zooko) Date: Thu, 15 May 2008 16:15:17 -0600 Subject: [Distutils] how do you express a platform-specific dependency? In-Reply-To: <454C9211-F9E8-4346-A453-4175A4813E77@zooko.com> References: <454C9211-F9E8-4346-A453-4175A4813E77@zooko.com> Message-ID: <80B72408-5B77-40C4-A402-7711CE93B1BA@zooko.com> On May 15, 2008, at 4:01 PM, zooko wrote: > Twisted requires pywin32 if it is running on Windows. How can the > twisted package metadata [1], which is produced by the twisted > setup.py [2], specify this dependency so that if you easy_install > Twisted on Windows you'll get pywin32 as well, but if you > easy_install Twisted on another platform you won't? ... > [1] http://pypi.python.org/pypi/Twisted > [2] http://twistedmatrix.com/trac/browser/trunk/setup.py?rev=23010#L76 Oh, following up to my own post, I guess the way you do it is put if sys.platform == 'win32': requirements.append('pywin32') If you do an install which involves fetching and evaluating the setup.py, this will suffice. What I don't understand is what happens if declarative metadata is generated, e.g. a "twisted.egg-info/ requires.txt" file which lists requirements. Will that file contain "pywin32" if Twisted was built on Windows but not if it was built elsewhere? Do those files get transferred around, such as in source distributions? Thanks, Regards, Zooko From pje at telecommunity.com Fri May 16 00:32:38 2008 From: pje at telecommunity.com (Phillip J. Eby) Date: Thu, 15 May 2008 18:32:38 -0400 Subject: [Distutils] how do you express a platform-specific dependency? In-Reply-To: <80B72408-5B77-40C4-A402-7711CE93B1BA@zooko.com> References: <454C9211-F9E8-4346-A453-4175A4813E77@zooko.com> <80B72408-5B77-40C4-A402-7711CE93B1BA@zooko.com> Message-ID: <20080515223216.E311F3A4061@sparrow.telecommunity.com> At 04:15 PM 5/15/2008 -0600, zooko wrote: >if sys.platform == 'win32': > requirements.append('pywin32') > >If you do an install which involves fetching and evaluating the >setup.py, this will suffice. What I don't understand is what happens >if declarative metadata is generated, e.g. a "twisted.egg-info/ >requires.txt" file which lists requirements. Will that file contain >"pywin32" if Twisted was built on Windows but not if it was built >elsewhere? Do those files get transferred around, such as in source >distributions? Yes... but when you test or install from a source distribution, those files get rebuilt. And of course, the binary distributions are platform-specific. From ncoghlan at gmail.com Fri May 16 00:49:22 2008 From: ncoghlan at gmail.com (Nick Coghlan) Date: Fri, 16 May 2008 08:49:22 +1000 Subject: [Distutils] [Python-Dev] Distutils & configparser rename In-Reply-To: <20080515203353.GA24080@amk-desktop.matrixgroup.net> References: <20080515203353.GA24080@amk-desktop.matrixgroup.net> Message-ID: <482CBDF2.3050206@gmail.com> A.M. Kuchling wrote: > Python 2.6 renames the ConfigParser module to be configparser. > > Distutils imports ConfigParser in various places. I just made a > commit updating the import in one places, and then noticed that part > of commit r63248, which made the same change, was reverted in order to > preserve backward-compatibility. Instead, the default path will > include lib-old again to keep the old module name available. Well, lib-old got added back to the path to support external users (since the deprecated ConfigParser name will emit a warning only under the -3 Py3k warning flag). Since it would be nice for the standard library to not emit any warnings with the -3 flag, perhaps distutils should at least be trying the new name first, and only falling back to the old name on an ImportError (assuming we do decide we want to be able to run the 2.6 distutils on older versions of Python). Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org From brett at python.org Fri May 16 01:04:45 2008 From: brett at python.org (Brett Cannon) Date: Thu, 15 May 2008 16:04:45 -0700 Subject: [Distutils] [Python-Dev] Distutils & configparser rename In-Reply-To: <20080515203353.GA24080@amk-desktop.matrixgroup.net> References: <20080515203353.GA24080@amk-desktop.matrixgroup.net> Message-ID: On Thu, May 15, 2008 at 1:33 PM, A.M. Kuchling wrote: > Python 2.6 renames the ConfigParser module to be configparser. > > Distutils imports ConfigParser in various places. I just made a > commit updating the import in one places, and then noticed that part > of commit r63248, which made the same change, was reverted in order to > preserve backward-compatibility. Instead, the default path will > include lib-old again to keep the old module name available. > > I suggest dropping that goal, though. We've preserved compatibility > but I'm not aware that anyone uses the Python 2.x Distutils with > earlier versions of Python. In particular: > > * There's no standalone distutils package on PyPI, nor can I find > such a package with a general web search. Am I missing it? > > * I do not see users advising other users to use a later version of > Distutils to fix their problems. > > Is anyone actually benefiting from the effort of maintaining backward > compatibility? The change was reverted at MAL's request, but he didn't qualify it beyond wanting the backwards-compatibility. -Brett From rasmus at flajm.se Fri May 16 01:11:40 2008 From: rasmus at flajm.se (Rasmus Andersson) Date: Fri, 16 May 2008 01:11:40 +0200 Subject: [Distutils] Failing to upload signed Egg: invalid distribution file (bdist_egg upload) Message-ID: <49333E64-3675-4553-879D-7D098C72F863@flajm.se> Hi everyone, I'm trying to use the upload command to upload binary eggs, but it seems PyPI has changed their upload form, because upload fails with the message: 400 Error processing form invalid distribution file See attached logs of: 1) bdist.txt -- Running setup.py bdist --sign upload with SUCCESS 2) bdist_egg.txt -- Running setup.py bdist_edd --sign upload with FAILURE setuptools 0.6c8 Python 2.5.1 (macports) Mac OS X 10.5.2 b9C7010 i386 -- Rasmus Andersson -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: bdist.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: bdist_egg.txt URL: From greg at krypto.org Fri May 16 06:08:13 2008 From: greg at krypto.org (Gregory P. Smith) Date: Thu, 15 May 2008 21:08:13 -0700 Subject: [Distutils] [Python-Dev] Distutils & configparser rename In-Reply-To: References: <20080515203353.GA24080@amk-desktop.matrixgroup.net> Message-ID: <52dc1c820805152108wc386902u7cacd9e7f5ae812d@mail.gmail.com> On Thu, May 15, 2008 at 4:04 PM, Brett Cannon wrote: > On Thu, May 15, 2008 at 1:33 PM, A.M. Kuchling wrote: >> Python 2.6 renames the ConfigParser module to be configparser. >> >> Distutils imports ConfigParser in various places. I just made a >> commit updating the import in one places, and then noticed that part >> of commit r63248, which made the same change, was reverted in order to >> preserve backward-compatibility. Instead, the default path will >> include lib-old again to keep the old module name available. >> >> I suggest dropping that goal, though. We've preserved compatibility >> but I'm not aware that anyone uses the Python 2.x Distutils with >> earlier versions of Python. In particular: >> >> * There's no standalone distutils package on PyPI, nor can I find >> such a package with a general web search. Am I missing it? >> >> * I do not see users advising other users to use a later version of >> Distutils to fix their problems. >> >> Is anyone actually benefiting from the effort of maintaining backward >> compatibility? > > The change was reverted at MAL's request, but he didn't qualify it > beyond wanting the backwards-compatibility. > > -Brett backwards compatibility? whats wrong with just doing: try: import configparser as ConfigParser except ImportError: import ConfigParser in the distutils code that needs to be. From brett at python.org Fri May 16 07:18:53 2008 From: brett at python.org (Brett Cannon) Date: Thu, 15 May 2008 22:18:53 -0700 Subject: [Distutils] [Python-Dev] Distutils & configparser rename In-Reply-To: <52dc1c820805152108wc386902u7cacd9e7f5ae812d@mail.gmail.com> References: <20080515203353.GA24080@amk-desktop.matrixgroup.net> <52dc1c820805152108wc386902u7cacd9e7f5ae812d@mail.gmail.com> Message-ID: On Thu, May 15, 2008 at 9:08 PM, Gregory P. Smith wrote: > On Thu, May 15, 2008 at 4:04 PM, Brett Cannon wrote: >> On Thu, May 15, 2008 at 1:33 PM, A.M. Kuchling wrote: >>> Python 2.6 renames the ConfigParser module to be configparser. >>> >>> Distutils imports ConfigParser in various places. I just made a >>> commit updating the import in one places, and then noticed that part >>> of commit r63248, which made the same change, was reverted in order to >>> preserve backward-compatibility. Instead, the default path will >>> include lib-old again to keep the old module name available. >>> >>> I suggest dropping that goal, though. We've preserved compatibility >>> but I'm not aware that anyone uses the Python 2.x Distutils with >>> earlier versions of Python. In particular: >>> >>> * There's no standalone distutils package on PyPI, nor can I find >>> such a package with a general web search. Am I missing it? >>> >>> * I do not see users advising other users to use a later version of >>> Distutils to fix their problems. >>> >>> Is anyone actually benefiting from the effort of maintaining backward >>> compatibility? >> >> The change was reverted at MAL's request, but he didn't qualify it >> beyond wanting the backwards-compatibility. >> >> -Brett > > backwards compatibility? whats wrong with just doing: > > try: > import configparser as ConfigParser > except ImportError: > import ConfigParser > > in the distutils code that needs to be. > Nothing's wrong with it. It's just that Alexandre did what we have done for all of the stdlib and just moved entirely over to the new name. -Brett From mal at egenix.com Fri May 16 15:00:26 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Fri, 16 May 2008 15:00:26 +0200 Subject: [Distutils] [Python-Dev] Distutils & configparser rename In-Reply-To: <20080515203353.GA24080@amk-desktop.matrixgroup.net> References: <20080515203353.GA24080@amk-desktop.matrixgroup.net> Message-ID: <482D856A.802@egenix.com> On 2008-05-15 22:33, A.M. Kuchling wrote: > Python 2.6 renames the ConfigParser module to be configparser. > > Distutils imports ConfigParser in various places. I just made a > commit updating the import in one places, and then noticed that part > of commit r63248, which made the same change, was reverted in order to > preserve backward-compatibility. Instead, the default path will > include lib-old again to keep the old module name available. > > I suggest dropping that goal, though. We've preserved compatibility > but I'm not aware that anyone uses the Python 2.x Distutils with > earlier versions of Python. In particular: > > * There's no standalone distutils package on PyPI, nor can I find > such a package with a general web search. Am I missing it? > > * I do not see users advising other users to use a later version of > Distutils to fix their problems. > > Is anyone actually benefiting from the effort of maintaining backward > compatibility? Yes: all the folks who want to create distutils packages for more than just the current Python version. I've argued for this a couple of times in the past. Some background: In order to build a Python package for a previous Python version, you have to run distutils using that older Python version. Now, as distutils evolves, new features are added, bugs are fixed, etc. so as packager you always want to use the latest distutils version available - even with older Python releases. In some cases, e.g. PyPI registration, this may even be necessary, since the new versions of those commands need to be kept in sync with the PyPI repository. Another aspect is keeping package setup.py files working. If you need to support multiple Python versions, then your setup.py will have to work with multiple different versions of distutils. Since performance doesn't really matter for distutils, it is well possible and easy to keep compatibility with a few releases back. This has worked great in the past and I don't see why we should break this, as recent distutils checkins have done. Note that Python doesn't exactly make it easy to ship Python packages. You have several different dimensions to take into consideration: * Python version * UCS2/UCS4 * Platform and processor type * 32/64-bit So there already is a lot of porting effort needed to support a reasonable number of targets. I don't think it takes a lot of effort to keep distutils running with Python 2.3 and 2.4. In the past I've usually rewritten parts of distutils that were modified in incompatible ways. I haven't been able to that for the recent checkins that broke distutils even on Python 2.4. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 16 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From rasmus at flajm.se Fri May 16 15:28:05 2008 From: rasmus at flajm.se (Rasmus Andersson) Date: Fri, 16 May 2008 15:28:05 +0200 Subject: [Distutils] [Python-Dev] Distutils & configparser rename In-Reply-To: <482D856A.802@egenix.com> References: <20080515203353.GA24080@amk-desktop.matrixgroup.net> <482D856A.802@egenix.com> Message-ID: On 16 maj 2008, at 15.00, M.-A. Lemburg wrote: > On 2008-05-15 22:33, A.M. Kuchling wrote: >> > > So there already is a lot of porting effort needed to support > a reasonable number of targets. > > I don't think it takes a lot of effort to keep distutils > running with Python 2.3 and 2.4. Speaking of which; is there any reliable statistics of Python versions and platforms? Would be really interesting! From mal at egenix.com Fri May 16 15:47:03 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Fri, 16 May 2008 15:47:03 +0200 Subject: [Distutils] [Python-Dev] Distutils & configparser rename In-Reply-To: References: <20080515203353.GA24080@amk-desktop.matrixgroup.net> <482D856A.802@egenix.com> Message-ID: <482D9057.3060602@egenix.com> On 2008-05-16 15:28, Rasmus Andersson wrote: > > On 16 maj 2008, at 15.00, M.-A. Lemburg wrote: > >> On 2008-05-15 22:33, A.M. Kuchling wrote: >>> >> >> So there already is a lot of porting effort needed to support >> a reasonable number of targets. >> >> I don't think it takes a lot of effort to keep distutils >> running with Python 2.3 and 2.4. > > Speaking of which; is there any reliable statistics of Python versions > and platforms? Would be really interesting! Reliable statistics are hard to obtain, since Python is distributed along with many Unix distributions, as part of many products, and also in source form (where you basically lose any platform or Python version information). FWIW, these are the stats for our OSS Python package egenix-mx-base: Downloads egenix-mx-base 3.0 in 2008: Python 1.5.2: 0 Python 2.0 : 0 Python 2.1 : 31 Python 2.2 : 54 Python 2.3 : 483 Python 2.4 : 3368 Python 2.5 : 7504 Source ZIP : 4238 Source TGZ : 2918 These are just downloads, so likely new installations (the 3.0 version was released about one year ago). It's hard to tell what the installed user base looks like, esp with respect to the used Python versions. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 16 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From rasmus at flajm.se Fri May 16 16:15:29 2008 From: rasmus at flajm.se (Rasmus Andersson) Date: Fri, 16 May 2008 16:15:29 +0200 Subject: [Distutils] [Python-Dev] Distutils & configparser rename In-Reply-To: <482D9057.3060602@egenix.com> References: <20080515203353.GA24080@amk-desktop.matrixgroup.net> <482D856A.802@egenix.com> <482D9057.3060602@egenix.com> Message-ID: On 16 maj 2008, at 15.47, M.-A. Lemburg wrote: > On 2008-05-16 15:28, Rasmus Andersson wrote: >> On 16 maj 2008, at 15.00, M.-A. Lemburg wrote: >>> On 2008-05-15 22:33, A.M. Kuchling wrote: >>>> >>> >>> So there already is a lot of porting effort needed to support >>> a reasonable number of targets. >>> >>> I don't think it takes a lot of effort to keep distutils >>> running with Python 2.3 and 2.4. >> Speaking of which; is there any reliable statistics of Python >> versions and platforms? Would be really interesting! > > Reliable statistics are hard to obtain, since Python is distributed > along > with many Unix distributions, as part of many products, and also in > source form (where you basically lose any platform or Python version > information). > > FWIW, these are the stats for our OSS Python package egenix-mx-base: > > Downloads egenix-mx-base 3.0 in 2008: > Python 1.5.2: 0 > Python 2.0 : 0 > Python 2.1 : 31 > Python 2.2 : 54 > Python 2.3 : 483 > Python 2.4 : 3368 > Python 2.5 : 7504 > Source ZIP : 4238 > Source TGZ : 2918 > > These are just downloads, so likely new installations (the 3.0 > version was released about one year ago). It's hard to tell what > the installed user base looks like, esp with respect to the used > Python versions. Thank you. That's better than nothing alright! > > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, May 16 > 2008) > >>> Python/Zope Consulting and Support ... http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ > ________________________________________________________________________ > > :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for > free ! :::: > > > eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > Registered at Amtsgericht Duesseldorf: HRB 46611 From andrewfr_ice at yahoo.com Fri May 16 18:01:08 2008 From: andrewfr_ice at yahoo.com (Andrew Francis) Date: Fri, 16 May 2008 09:01:08 -0700 (PDT) Subject: [Distutils] Problem with Setuptools on Ubuntu 8.0.4 In-Reply-To: <482BFCDC.7010507@lbruno.org> Message-ID: <380773.85238.qm@web34205.mail.mud.yahoo.com> Hi Luis: --- Luis Bruno wrote: > IIRC, python2.5-minimal is part of the default > installation. Reinstall > that package and find out what caused that file to > go away. Thanks for the advice. I left out an important piece of information - I installed Stackless Python on my system. I think the problems lie with the Stackless Python setup. Cheers, Andrew From mmanns at gmx.net Mon May 19 23:28:47 2008 From: mmanns at gmx.net (Martin Manns) Date: Mon, 19 May 2008 21:28:47 +0000 (UTC) Subject: [Distutils] Duplicate files in site-packages and sub-folder Message-ID: Hi, I have the following problem with the distutils package: (I have now spent hours reading and searching the manuals and tutorials, and I am still stuck.) I have a working directory ~/pyspread in which my libraries are situated and two icons directories ~/pyspread/icons and ~/pyspread/icons/actions Now I would like to create a setup.py file inside my ~/pyspread directory that installs my .py modules in .../site-packages/pyspread and the icons in appropriate sub-folders and adds pyspread.pth to .../site-packages so that .../site-packages/pyspread is in the PYTHONPATH. However, my setup.py puts everything (including .pyc files) into site-packages *and* into the sub-folders. What am I doing wrong? I am looking for a platform-independent solution. Currently, I am using python 2.5 on Linux. Here my setup.py #!/usr/bin/env python from distutils.core import setup setup(name='pyspread', version='0.0.7', description='A spreadsheet that accepts a pure python expression in each cell.', license='GPL v3 :: GNU General Public License', classifiers=[ 'Development Status :: 3 - Alpha', 'Intended Audience :: End Users/Desktop', ], author='Martin Manns', author_email='mmanns at gmx.net', url='http://sourceforge.net/projects/pyspread/', packages=['pyspread'], package_dir={'pyspread': '.'}, scripts=['pyspread.py'], py_modules=['pyspread.mainapp', 'pyspread.pysgrid', 'pyspread.mygrid','pyspread.icontheme'], package_data={'pyspread': ['icons/*.png', 'icons/actions/*.png' ,\ 'test.pys', 'test.csv', 'test2.csv', \ 'README', 'COPYING']}, ) Thanks in advance Martin From ronaldoussoren at mac.com Tue May 20 12:15:30 2008 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 20 May 2008 12:15:30 +0200 Subject: [Distutils] Duplicate files in site-packages and sub-folder In-Reply-To: References: Message-ID: <05530E32-9302-40A7-829A-8412494C0B8A@mac.com> Martin, The py_modules line in your setup.py is not necessary (they are part of the package that is mentioned earlier). Ronald On 19 May, 2008, at 23:28, Martin Manns wrote: > Hi, > > I have the following problem with the distutils package: > (I have now spent hours reading and searching the manuals and > tutorials, > and I am still stuck.) > > I have a working directory > ~/pyspread > in which my libraries are situated and two icons directories > ~/pyspread/icons and ~/pyspread/icons/actions > > Now I would like to create a setup.py file inside my ~/pyspread > directory that installs my .py modules in .../site-packages/pyspread > and the icons in appropriate sub-folders and adds pyspread.pth to > .../site-packages so that .../site-packages/pyspread is in the > PYTHONPATH. > > However, my setup.py puts everything (including .pyc files) into > site-packages *and* into the sub-folders. What am I doing wrong? > > I am looking for a platform-independent solution. Currently, I am > using > python 2.5 on Linux. > > Here my setup.py > > #!/usr/bin/env python > > from distutils.core import setup > setup(name='pyspread', > version='0.0.7', > description='A spreadsheet that accepts a pure python > expression in each > cell.', > license='GPL v3 :: GNU General Public License', > classifiers=[ 'Development Status :: 3 - Alpha', > 'Intended Audience :: End Users/Desktop', > ], > author='Martin Manns', > author_email='mmanns at gmx.net', > url='http://sourceforge.net/projects/pyspread/', > packages=['pyspread'], > package_dir={'pyspread': '.'}, > scripts=['pyspread.py'], > py_modules=['pyspread.mainapp', 'pyspread.pysgrid', > 'pyspread.mygrid','pyspread.icontheme'], > package_data={'pyspread': ['icons/*.png', 'icons/actions/ > *.png' ,\ > 'test.pys', 'test.csv', 'test2.csv', \ > 'README', 'COPYING']}, > ) > > > Thanks in advance > > Martin > > > > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG at python.org > http://mail.python.org/mailman/listinfo/distutils-sig From mmanns at gmx.net Wed May 21 21:21:19 2008 From: mmanns at gmx.net (Martin Manns) Date: Wed, 21 May 2008 19:21:19 +0000 (UTC) Subject: [Distutils] Duplicate files in site-packages and sub-folder References: <05530E32-9302-40A7-829A-8412494C0B8A@mac.com> Message-ID: Ronald Oussoren mac.com> writes: > The py_modules line in your setup.py is not necessary (they are part > of the package that is mentioned earlier). It worked! Thank you. Martin From hjebbers at gmail.com Thu May 22 20:43:21 2008 From: hjebbers at gmail.com (henk-jan ebbers) Date: Thu, 22 May 2008 20:43:21 +0200 Subject: [Distutils] how to set installation directory on windows using bdist_wininst Message-ID: <4835BEC9.5090504@gmail.com> how do I 'contrl' the place where an python application is put on the system where it will be installed? Is this possible using distutils? preferably this would be (according to windows customs) something like 'c:\program files\myappl' Is is possible to let the user choose another place than the default place? (I see a lot of talk about disutils better suited for for 'modules' than application, I am aware of this. No, I can not use py2exe; I have good reasons for that.) thanks in advance, henk-jan From setuptools at bugs.python.org Fri May 23 19:37:50 2008 From: setuptools at bugs.python.org (htgoebel) Date: Fri, 23 May 2008 17:37:50 +0000 Subject: [Distutils] [issue11] bdist_wininst adds duplicate entry to dist_files In-Reply-To: <1211564263.15.0.978803863777.issue11@psf.upfronthosting.co.za> Message-ID: <1211564263.15.0.978803863777.issue11@psf.upfronthosting.co.za> New submission from htgoebel : In setuptools 0.6c8 has a bug in bdist_wininst: Distribution files are listed twice ``distribution.dist_files``. This hinders developing tools which use this data. In addition ``upload`` will upload the file twice to pypi. I need this bug fixed for automated upload of files using ;;. Enclosed please find a simple package to show the bug. Just run python setup.py bdist_wininst this shows one entry. Now run python setup-setuptools.py bdist_wininst this shows two entires. The only difference between both setup files is wherefrom setup() is imported. ---------- files: simple-0.0.0.0.1.tar.gz messages: 15 nosy: htgoebel priority: bug status: unread title: bdist_wininst adds duplicate entry to dist_files Added file: http://bugs.python.org/setuptools/file6/simple-0.0.0.0.1.tar.gz _______________________________________________ Setuptools tracker _______________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: simple-0.0.0.0.1.tar.gz Type: application/x-gzip Size: 903 bytes Desc: not available URL: From h.goebel at goebel-consult.de Fri May 23 19:59:30 2008 From: h.goebel at goebel-consult.de (Hartmut Goebel) Date: Fri, 23 May 2008 19:59:30 +0200 Subject: [Distutils] adding commands by just "import my.module" Message-ID: <48370602.9050304@goebel-consult.de> Hi, I'm currentyl implementing a module to automatically submit releases to the Origo open software development platform . So I'm looking for for adding the new command (origo_submit) to distutils as simple as possible. So I imaging, the user only does a from import distutils.core import setup import origo.submit setup(...) How to register my new command to distutils from origo.submit? (This is already working using setuptools entry_points ={...}, but I'm looking for some easier way for the user.) -- Sch?nen Gru? - Regards Hartmut Goebel Goebel Consult Spezialist f?r IT-Sicherheit in komplexen Umgebungen http://www.goebel-consult.de -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3195 bytes Desc: S/MIME Cryptographic Signature URL: From setuptools at bugs.python.org Tue May 27 14:12:13 2008 From: setuptools at bugs.python.org (htgoebel) Date: Tue, 27 May 2008 12:12:13 +0000 Subject: [Distutils] [issue12] add option --download-only In-Reply-To: <1211890333.49.0.201375619221.issue12@psf.upfronthosting.co.za> Message-ID: <1211890333.49.0.201375619221.issue12@psf.upfronthosting.co.za> New submission from htgoebel : Please add an option --download-only (or suchlike). Some packages can not be installed using setup.py install, since they do not support distutils. But if easy_install would support an option like --download-only, it could be used to download the newest version and all dependencies. ---------- messages: 16 nosy: htgoebel priority: wish status: unread title: add option --download-only _______________________________________________ Setuptools tracker _______________________________________________ From setuptools at bugs.python.org Tue May 27 15:33:47 2008 From: setuptools at bugs.python.org (Kirill Smelkov) Date: Tue, 27 May 2008 13:33:47 +0000 Subject: [Distutils] [issue13] wish: silent mode for bdist_wininst created installers In-Reply-To: <1211895227.5.0.984326943812.issue13@psf.upfronthosting.co.za> Message-ID: <1211895227.5.0.984326943812.issue13@psf.upfronthosting.co.za> New submission from Kirill Smelkov : Recently I've tried to package python software into small in-house win32 distribution, and I had no luck to get it installing in auto mode. The problem is that bdist_wininst created installers do not support runtime options, and according to source files in PC/bdist_wininst/ there is no way to perform auto installation. This is in contrast to bdist_msi created installers, nsis installers, etc, who support one way or the other silent installation. E.g. for msi installers the following work: msiexec /i package.msi /qb for nsis installers, "/S" option works ./package.exe /S But there is just no way to install bdist_wininst created packages in silent mode. ---- So I'd like to join my "+1" to one of the wish from DistUtils20 wiki page: http://wiki.python.org/moin/DistUtils20 """ It would be great if installers generated by bdist_wininst supported a 'silent' flag for automated installs. The silent mode would allow the package to be installed without user intervention. -- Phil Rittenhouse """ +1, it would be really handy! ---- I think it is very inconvenient that default way for creating windows installers lacks it. ---------- messages: 17 nosy: kirr priority: wish status: unread title: wish: silent mode for bdist_wininst created installers _______________________________________________ Setuptools tracker _______________________________________________ From mhammond at skippinet.com.au Tue May 27 16:22:39 2008 From: mhammond at skippinet.com.au (Mark Hammond) Date: Wed, 28 May 2008 00:22:39 +1000 Subject: [Distutils] [issue13] wish: silent mode for bdist_wininst created installers In-Reply-To: <1211895227.5.0.984326943812.issue13@psf.upfronthosting.co.za> References: <1211895227.5.0.984326943812.issue13@psf.upfronthosting.co.za> <1211895227.5.0.984326943812.issue13@psf.upfronthosting.co.za> Message-ID: <027201c8c005$20975fe0$61c61fa0$@com.au> I hope the tracker can cope with these ad-hoc replies: > But there is just no way to install bdist_wininst created packages in > silent mode. Sadly there is no way - but this is technically a limitation of distutils, not setuptools. Patches would be accepted for this though, and please don't be shy in asking for help if this is what you choose to do. Mark. From setuptools at bugs.python.org Fri May 30 18:09:18 2008 From: setuptools at bugs.python.org (Zooko O'Whielacronx) Date: Fri, 30 May 2008 16:09:18 +0000 Subject: [Distutils] [issue14] Executing "./ez_setup.py" fails. In-Reply-To: <1212163758.13.0.0315232428985.issue14@psf.upfronthosting.co.za> Message-ID: <1212163758.13.0.0315232428985.issue14@psf.upfronthosting.co.za> New submission from Zooko O'Whielacronx : On my Mac: $ ./ez_setup.py bash: ./ez_setup.py: python: bad interpreter: No such file or directory On Cygwin I get the same sort of error. Replacing the shebang line "#!python" with "#!/usr/bin/env python" fixes this problem. I've tested this fix on Mac, Linux, Solaris, Cygwin, and Windows. ---------- messages: 18 nosy: zooko priority: bug status: unread title: Executing "./ez_setup.py" fails. _______________________________________________ Setuptools tracker _______________________________________________ From setuptools at bugs.python.org Fri May 30 18:17:41 2008 From: setuptools at bugs.python.org (Zooko O'Whielacronx) Date: Fri, 30 May 2008 16:17:41 +0000 Subject: [Distutils] [issue15] easy_install won't tell you what version it is In-Reply-To: <1212164261.56.0.310651313377.issue15@psf.upfronthosting.co.za> Message-ID: <1212164261.56.0.310651313377.issue15@psf.upfronthosting.co.za> New submission from Zooko O'Whielacronx : I'm wondering what version of "easy_install" I have here. "easy_install --version" doesn't work, and "easy_install --help" doesn't mention the version number. ---------- messages: 19 nosy: zooko priority: bug status: unread title: easy_install won't tell you what version it is _______________________________________________ Setuptools tracker _______________________________________________ From setuptools at bugs.python.org Fri May 30 20:29:22 2008 From: setuptools at bugs.python.org (Zooko O'Whielacronx) Date: Fri, 30 May 2008 18:29:22 +0000 Subject: [Distutils] [issue16] permission error in untarring pyOpenSSL-0.6.tar.gz In-Reply-To: <1212172161.94.0.300964812081.issue16@psf.upfronthosting.co.za> Message-ID: <1212172161.94.0.300964812081.issue16@psf.upfronthosting.co.za> New submission from Zooko O'Whielacronx : Running easy_install on pyOpenSSL-0.6.tar.gz ends with: File "/usr/local/stow/python-release25-maint-2008-05-30/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/setuptools/command/easy_install.py", line 626, in install_eggs unpack_archive(dist_filename, tmpdir, self.unpack_progress) File "/usr/local/stow/python-release25-maint-2008-05-30/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/setuptools/archive_util.py", line 67, in unpack_archive driver(filename, extract_dir, progress_filter) File "/usr/local/stow/python-release25-maint-2008-05-30/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/setuptools/archive_util.py", line 192, in unpack_tarfile tarobj._extract_member(member,dst) # XXX Ugh File "/usr/local/stow/python-release25-maint-2008-05-30/lib/python2.5/tarfile.py", line 1656, in _extract_member self.chmod(tarinfo, targetpath) File "/usr/local/stow/python-release25-maint-2008-05-30/lib/python2.5/tarfile.py", line 1777, in chmod raise ExtractError("could not change mode of %s to mode %o (octal), exception: %s" % (targetpath, tarinfo.mode, e)) tarfile.ExtractError: could not change mode of /tmp/easy_install-4yCggq/pyOpenSSL-0.6 to mode 2755 (octal), exception: [Errno 1] Operation not permitted: '/tmp/easy_install-4yCggq/pyOpenSSL-0.6' If I untar that tarball with GNU tar, I see that there is one file that doesn't have read permissions for user or group: ... -rw-r--r-- martin/martin 1289 2002-09-07 09:28:12 pyOpenSSL-0.6/examples/simple/client.py -rw-r--r-- martin/martin 1863 2004-07-22 06:01:25 pyOpenSSL-0.6/examples/proxy.py -rw------- martin/martin 3508 2002-09-07 09:27:47 pyOpenSSL-0.6/examples/SecureXMLRPCServer.py -rw-r--r-- martin/martin 260 2004-07-22 06:01:25 pyOpenSSL-0.6/__init__.py ... If I rebuild that tarball with GNU tar ("tar czvvf pyOpenSSL-0.6.tar.gz pyOpenSSL") then the resulting tarball does not have that problem. So, I don't understand it, but there is something funny in the permissions in that official pyOpenSSL-0.6.tar.gz (from http://sourceforge.net/project/showfiles.php?group_id=31249 ) which causes this exception inside tarfile but which goes away if you unpack and repack the tarball on Mac OS X using GNU tar v1.14. This is probably more of a bug in tarfile.py than in setuptools proper, but I thought I should register this issue on the setuptools tracker so that we can think of some workaround to deploy before this gets fixed in Python tarfile.py and everyone in the world upgrades to the new tarfile.py... ---------- messages: 20 nosy: zooko priority: bug status: unread title: permission error in untarring pyOpenSSL-0.6.tar.gz _______________________________________________ Setuptools tracker _______________________________________________ From setuptools at bugs.python.org Sat May 31 03:13:11 2008 From: setuptools at bugs.python.org (Zooko O'Whielacronx) Date: Sat, 31 May 2008 01:13:11 +0000 Subject: [Distutils] [issue17] easy_install (debian sid version 0.6c8) will install a package that is already there In-Reply-To: <1212196390.99.0.402836850246.issue17@psf.upfronthosting.co.za> Message-ID: <1212196390.99.0.402836850246.issue17@psf.upfronthosting.co.za> New submission from Zooko O'Whielacronx : Tahoe ticket http://allmydata.org/trac/tahoe/ticket/229 -- describes a problem that I found on my home system, running debian/sid, when upgrading from the debian python-setuptools-0.6c7 to 0.6c8 . I have Nevow installed on this box, in a way that is visible to setuptools: specifically {{{import pkg_resources; pkg_resources.require("Nevow")}}} succeeds. However, with 0.6c8 installed, "easy_install Nevow" nevertheless attempts to download and install the latest version according to pypi. 0.6c7 did not: it saw the existing Nevow and refrained from downloading a new copy. I haven't done a lot of analysis of this yet. When Zooko and I looked at it about a month ago, we concluded that it was something specific to the debian 0.6c8 package: installing 0.6c8 from source on a different system did not seem to exhibit the bug. Downgrading to the debian 0.6c7 package resolved the problem. This has been reported to Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=475440 I believe that it is a bug specific to the Debian package of setuptools 0.6c8. It doesn't happen with setuptools 0.6c8 on other platforms, and it doesn't happen with the Debian package of setuptools 0.6c7. ---------- messages: 27 nosy: zooko priority: bug status: unread title: easy_install (debian sid version 0.6c8) will install a package that is already there _______________________________________________ Setuptools tracker _______________________________________________