From dangoor at gmail.com Fri Sep 1 21:26:06 2006 From: dangoor at gmail.com (Kevin Dangoor) Date: Fri, 1 Sep 2006 15:26:06 -0400 Subject: [Distutils] problem finding an entry point Message-ID: <3f085ecd0609011226i2c613e8bud61816705bf77d42@mail.gmail.com> We've got a custom packaging setup that I'm trying to integrate a Nose plugin into. I'm using a single-version-externally-managed setup. Our packaging setup uses symlinks to link from a package area on disk to /usr/local/lib/python2.4/site-packages. Running "python" from the command line shows the libraries coming from the package area, not /usr/local... For some reason, if I explicitly set my PYTHONPATH environment variable to include the /usr/local... directory it can find my plugin. If I don't set it, it can't find the plugin. (pkg_resources.require() can find my package and is able to confirm that the entry point is there...) While I have things working with the PYTHONPATH, I'd like to not have that requirement... any ideas what might keep this from working normally? Kevin -- Kevin Dangoor TurboGears / Zesty News email: kid at blazingthings.com company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com From pje at telecommunity.com Fri Sep 1 22:36:00 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Fri, 01 Sep 2006 16:36:00 -0400 Subject: [Distutils] problem finding an entry point In-Reply-To: <3f085ecd0609011226i2c613e8bud61816705bf77d42@mail.gmail.co m> Message-ID: <5.1.1.6.0.20060901163326.02b73590@sparrow.telecommunity.com> At 03:26 PM 9/1/2006 -0400, Kevin Dangoor wrote: >We've got a custom packaging setup that I'm trying to integrate a Nose >plugin into. I'm using a single-version-externally-managed setup. Our >packaging setup uses symlinks to link from a package area on disk to >/usr/local/lib/python2.4/site-packages. Running "python" from the >command line shows the libraries coming from the package area, not >/usr/local... > >For some reason, if I explicitly set my PYTHONPATH environment >variable to include the /usr/local... directory it can find my plugin. >If I don't set it, it can't find the plugin. (pkg_resources.require() >can find my package and is able to confirm that the entry point is >there...) I think you're going to need to be more specific here. I'm not clear on what is being found when, by what. I'm also not clear what is being symlinked where. >While I have things working with the PYTHONPATH, I'd like to not have >that requirement... any ideas what might keep this from working >normally? It's probably something to do with the symlinks, though it's hard to say what, exactly. pkg_resources contains some realpath() calls, but I'm not sure how they come into play in this scenario. More details, please. From pje at telecommunity.com Sat Sep 2 01:35:16 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Fri, 01 Sep 2006 19:35:16 -0400 Subject: [Distutils] Improving setuptools bootstrapping Message-ID: <5.1.1.6.0.20060901174954.02a52008@sparrow.telecommunity.com> So, I've been giving some thought to how setuptools does its bootstrap installation. One potentially-significant problem is that people are often installing older versions, because of old copies of ez_setup.py being distributed in people's packages. Right now, ez_setup.py is used for two purposes. First, you can include it in a source package in order to be able to use setuptools. Second, it's also used as a way of installing setuptools in a standalone setting. In both cases, there are two possibilities regarding the target machine: it may have network access, or it may not. If it does have access, the current approaches basically work okay, except for the versioning issue. If network access isn't available, however, it annoys users who are trying to install a setuptools-based package who don't already have setuptools. (Thus creating a bad impression for both setuptools *and* the package using it.) This isn't likely to remain a problem in the long term. As setuptools stabilizes, it will be more likely that the user already has a current and stable setuptools version installed. A later version of Python might even bundle it, and it's also relatively easy to create system packages of setuptools now. For example, I could go back to building .exe installers for Windows, and perhaps throw in Linux RPMs as well. (And perhaps get contributed Mac OS packages too.) Back when the current ez_setup.py system was created, this wasn't an option because system packages of eggs weren't well-supported, and version conflicts could occur if you tried to also install the egg version of something. But none of these things are issues any more. So it's possible that we could start phasing out ez_setup's automatic downloading, in favor of simply requesting that setuptools be installed first. The advantage is that ez_setup would become simpler and more stable, without version skew in its distributed versions. The disadvantage is that it requires an extra step to install, which might discourage user or developer adoption. But adoption appears to be quite widespread now; the Cheeseshop shows tens of thousands of downloads of setuptools 0.6c1 alone! So, perhaps we should move to doing something like this: when you run a setup.py that's using ez_setup(), and it appears necessary to download/install setuptools, a message is displayed, something like: ---------------------------------------------------------------- setuptools >= 0.6c1 not found Please install or upgrade the setuptools package before running this script; see http://cheeseshop.python.org/pypi/setuptools for downloads. ---------------------------------------------------------------- If there's a version of setuptools already on the machine, the message could also add something like this at the end: You may be able to upgrade your current installation of setuptools using 'easy_install -U setuptools'. This would reduce ez_setup.py to hardly any code at all. Pros: * Net-less installs are less painful * Users don't get surprised by "setup.py install" trying to access the net * No version skew or missing version issues * Users can install system packages (RPM, .exe, etc.) of setuptools Cons: * Manual step for new setuptools adopters (but who's left?) * Might break setuptools-wrapping programs (like zc.buildout and Enstaller) if they rely on ez_setup * Developers might not want to switch to this new approach, if they feel the manual step is unwieldy Does anybody have any thoughts on this, one way or the other? From rlratzel at enthought.com Sat Sep 2 02:15:38 2006 From: rlratzel at enthought.com (Rick Ratzel) Date: Fri, 1 Sep 2006 19:15:38 -0500 (CDT) Subject: [Distutils] Improving setuptools bootstrapping In-Reply-To: <5.1.1.6.0.20060901174954.02a52008@sparrow.telecommunity.com> (pje@telecommunity.com) References: <5.1.1.6.0.20060901174954.02a52008@sparrow.telecommunity.com> Message-ID: <20060902001538.BD125696@mail.enthought.com> Phillip, Regarding your concern about breaking setuptools-wrapping programs, don't worry about Enstaller. Yes, it does depend on the functionality that ez_setup.py currently provides at the moment, but the bootstrap code is easily changed to grab and install setuptools using other means (we have Enstaller handling eggs of everything from wxPython on Linux to MinGW on Windows, so I'm sure a change for something like this won't be a problem ;). We can have Enstaller default to finding the latest setuptools available if one isn't installed, or a specific version if the user requests it. A nice feature of Enstaller will be that another con you mentioned--the extra manual step for new setuptools adopters--also won't be an issue. > Date: Fri, 01 Sep 2006 19:35:16 -0400 > From: "Phillip J. Eby" > > So, I've been giving some thought to how setuptools does its bootstrap > installation. > > One potentially-significant problem is that people are often installing > older versions, because of old copies of ez_setup.py being distributed in > people's packages. > > Right now, ez_setup.py is used for two purposes. First, you can include it > in a source package in order to be able to use setuptools. Second, it's > also used as a way of installing setuptools in a standalone setting. > > In both cases, there are two possibilities regarding the target machine: it > may have network access, or it may not. If it does have access, the > current approaches basically work okay, except for the versioning > issue. If network access isn't available, however, it annoys users who are > trying to install a setuptools-based package who don't already have > setuptools. (Thus creating a bad impression for both setuptools *and* the > package using it.) > > This isn't likely to remain a problem in the long term. As setuptools > stabilizes, it will be more likely that the user already has a current and > stable setuptools version installed. A later version of Python might even > bundle it, and it's also relatively easy to create system packages of > setuptools now. > > For example, I could go back to building .exe installers for Windows, and > perhaps throw in Linux RPMs as well. (And perhaps get contributed Mac OS > packages too.) Back when the current ez_setup.py system was created, this > wasn't an option because system packages of eggs weren't well-supported, > and version conflicts could occur if you tried to also install the egg > version of something. But none of these things are issues any more. > > So it's possible that we could start phasing out ez_setup's automatic > downloading, in favor of simply requesting that setuptools be installed first. > > The advantage is that ez_setup would become simpler and more stable, > without version skew in its distributed versions. The disadvantage is that > it requires an extra step to install, which might discourage user or > developer adoption. > > But adoption appears to be quite widespread now; the Cheeseshop shows tens > of thousands of downloads of setuptools 0.6c1 alone! > > So, perhaps we should move to doing something like this: when you run a > setup.py that's using ez_setup(), and it appears necessary to > download/install setuptools, a message is displayed, something like: > > ---------------------------------------------------------------- > setuptools >= 0.6c1 not found > > Please install or upgrade the setuptools package before running > this script; see http://cheeseshop.python.org/pypi/setuptools > for downloads. > ---------------------------------------------------------------- > > If there's a version of setuptools already on the machine, the message > could also add something like this at the end: > > You may be able to upgrade your current installation of > setuptools using 'easy_install -U setuptools'. > > This would reduce ez_setup.py to hardly any code at all. > > Pros: > * Net-less installs are less painful > * Users don't get surprised by "setup.py install" trying to access the net > * No version skew or missing version issues > * Users can install system packages (RPM, .exe, etc.) of setuptools > > Cons: > * Manual step for new setuptools adopters (but who's left?) > * Might break setuptools-wrapping programs (like zc.buildout and > Enstaller) if they rely on ez_setup > * Developers might not want to switch to this new approach, if they feel > the manual step is unwieldy > > > Does anybody have any thoughts on this, one way or the other? > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG at python.org > http://mail.python.org/mailman/listinfo/distutils-sig > > -- Rick Ratzel - Enthought, Inc. 515 Congress Avenue, Suite 2100 - Austin, Texas 78701 512-536-1057 x229 - Fax: 512-536-1059 http://www.enthought.com From dangoor at gmail.com Tue Sep 5 13:56:21 2006 From: dangoor at gmail.com (Kevin Dangoor) Date: Tue, 5 Sep 2006 07:56:21 -0400 Subject: [Distutils] problem finding an entry point In-Reply-To: <5.1.1.6.0.20060901163326.02b73590@sparrow.telecommunity.com> References: <5.1.1.6.0.20060901163326.02b73590@sparrow.telecommunity.com> Message-ID: <3f085ecd0609050456o5900da7am1e883f47bb2523a5@mail.gmail.com> On 9/1/06, Phillip J. Eby wrote: > I think you're going to need to be more specific here. I'm not clear on > what is being found when, by what. I'm also not clear what is being > symlinked where. OK, here are specifics.... Things in /base/pkg/Foo/usr/local/lib/python2.4/site-packages are linked over to /usr/local/lib/python2.4/site-packages. (I doubt it makes a difference, but this whole thing is actually run in a chrooted environment...) It appears that in most instances (and I don't know enough about the packager to know which instances and why), the directories are real directories, but the files inside are symlinks. Specifically: /usr/local/lib/python2.4/site-packages/nose would be a real directory /usr/local/lib/python2.4/site-packages/nose/result.py is a symlink to /base/pkg/Foo/usr/local/lib/python2.4/site-packages/nose/result.py There's a nose-0.9.0-py2.4.egg-info directory next to the nose directory (again, the directory is real but the files inside are symlinks). One more important thing to know about this setup. We have a couple of different packages in /base/pkg, and they both contribute to /usr/local/lib... When you run python, the /baes/pkg... path for the package that contains Python is what shows up in sys.path (not /usr/local/lib/python2.4/site-packages). We created a sitecustomize.py file to add /usr/local/lib/python2.4/site-packages as a sitedir. We're able to import all of the python packages from that directory just fine. But, I wrote a nose plugin that is only found if I explicitly set a PYTHONPATH environment variable to point to /usr/local/lib/python2.4/site-packages. >From the Python prompt, if I iter_entry_points, I don't see my plugin without the PYTHONPATH. However, I can require my package and see the entry point via the API. Hopefully that makes it clearer... Kevin From jim at zope.com Tue Sep 5 16:48:18 2006 From: jim at zope.com (Jim Fulton) Date: Tue, 5 Sep 2006 10:48:18 -0400 Subject: [Distutils] Improving setuptools bootstrapping In-Reply-To: <5.1.1.6.0.20060901174954.02a52008@sparrow.telecommunity.com> References: <5.1.1.6.0.20060901174954.02a52008@sparrow.telecommunity.com> Message-ID: <9E0E9576-1042-4538-873D-E63581C41CE2@zope.com> On Sep 1, 2006, at 7:35 PM, Phillip J. Eby wrote: ... > Right now, ez_setup.py is used for two purposes. First, you can > include it in a source package in order to be able to use > setuptools. Second, it's also used as a way of installing > setuptools in a standalone setting. ... > So, perhaps we should move to doing something like this: when you > run a setup.py that's using ez_setup(), and it appears necessary to > download/install setuptools, a message is displayed, something like: .... > This would reduce ez_setup.py to hardly any code at all. > > Pros: > * Net-less installs are less painful > * Users don't get surprised by "setup.py install" trying to > access the net > * No version skew or missing version issues > * Users can install system packages (RPM, .exe, etc.) of setuptools > > Cons: > * Manual step for new setuptools adopters (but who's left?) > * Might break setuptools-wrapping programs (like zc.buildout and > Enstaller) if they rely on ez_setup > * Developers might not want to switch to this new approach, if > they feel the manual step is unwieldy > > > Does anybody have any thoughts on this, one way or the other? +1 However, this only addresses the first use case above. I still like ez_setup for the second use case. In particular, the zc.buildout bootstrap script lets ez_setup do most of it's work. It downloads a fresh copy of ez_setup and uses it to download setuptools and zc.buildout. Part of what makes this work is the fact that ez_setup has a well-known URL, so my bootstrap script, http://svn.zope.org/zc.buildout/trunk/bootstrap/bootstrap.py? view=auto can be pretty stupid and minimal. Of course, if ez_setup went away, I'd cope. :) Jim -- Jim Fulton mailto:jim at zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org From pje at telecommunity.com Wed Sep 6 06:13:28 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed, 06 Sep 2006 00:13:28 -0400 Subject: [Distutils] Improving setuptools bootstrapping In-Reply-To: <7.0.1.0.0.20060905130640.021d9988@telecommunity.com> Message-ID: <5.1.1.6.0.20060906000609.02c390e0@unrestrained.com> At 01:06 PM 9/5/2006 -0700, Jim Fulton wrote: >On Sep 1, 2006, at 7:35 PM, Phillip J. Eby wrote: >... >>Right now, ez_setup.py is used for two purposes. First, you can >>include it in a source package in order to be able to use >>setuptools. Second, it's also used as a way of installing >>setuptools in a standalone setting. >... >>So, perhaps we should move to doing something like this: when you >>run a setup.py that's using ez_setup(), and it appears necessary to >>download/install setuptools, a message is displayed, something like: > >.... > >>This would reduce ez_setup.py to hardly any code at all. >> >>Pros: >> * Net-less installs are less painful >> * Users don't get surprised by "setup.py install" trying to >>access the net >> * No version skew or missing version issues >> * Users can install system packages (RPM, .exe, etc.) of setuptools >> >>Cons: >> * Manual step for new setuptools adopters (but who's left?) >> * Might break setuptools-wrapping programs (like zc.buildout and >>Enstaller) if they rely on ez_setup >> * Developers might not want to switch to this new approach, if >>they feel the manual step is unwieldy >> >> >>Does anybody have any thoughts on this, one way or the other? > >+1 > >However, this only addresses the first use case above. I still like >ez_setup for the second use case. Well, the theory behind this approach for the second case is that if we have options to install setuptools via system-specific packages (RPM, .deb, .exe, etc.), then this could be a required prerequisite, not unlike installing Python itself. > In particular, the zc.buildout >bootstrap script lets ez_setup do most of it's work. It downloads a >fresh copy of ez_setup and uses it to download setuptools and >zc.buildout. Part of what makes this work is the fact that ez_setup >has a well-known URL, so my bootstrap script, >http://svn.zope.org/zc.buildout/trunk/bootstrap/bootstrap.py? view=auto >can be pretty stupid and minimal. True; of course, if setuptools is a standard system package, it's not much different than requiring Python to be installed first. And if setuptools becomes part of Python in 2.6, the issue goes away altogether. >Of course, if ez_setup went away, I'd cope. :) I've thought about changing ez_setup to use the PyPI XML-RPC interface to find the right download file, as that would remedy certain issues -- at the cost of still being problematic for network-deprived installations. It may be that the complete strategy needs to be to make platform-specific binary installation packages available, and for the bundling scenario change ez_setup to direct people to the binaries, but also offer a command-line option to request a download. For the standalone scenario, we would of course download. And the download should use PyPI's XML-RPC to select the latest stable version. From pje at telecommunity.com Wed Sep 6 16:18:05 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed, 06 Sep 2006 10:18:05 -0400 Subject: [Distutils] problem finding an entry point In-Reply-To: <3f085ecd0609060600r4e423151ie45f9500ae8e5a57@mail.gmail.co m> References: <5.1.1.6.0.20060906000145.026382e8@unrestrained.com> <7.0.1.0.0.20060905130716.021fb010@telecommunity.com> <5.1.1.6.0.20060906000145.026382e8@unrestrained.com> Message-ID: <5.1.1.6.0.20060906095352.026382d0@sparrow.telecommunity.com> At 09:00 AM 9/6/2006 -0400, Kevin Dangoor wrote: >On 9/6/06, Phillip J. Eby wrote: >>At 01:07 PM 9/5/2006 -0700, Kevin Dangoor wrote: >> >On 9/1/06, Phillip J. Eby wrote: >> >>I think you're going to need to be more specific here. I'm not clear on >> >>what is being found when, by what. I'm also not clear what is being >> >>symlinked where. >> > >> >OK, here are specifics.... >> > >> >Things in /base/pkg/Foo/usr/local/lib/python2.4/site-packages are >> >linked over to /usr/local/lib/python2.4/site-packages. (I doubt it >> >makes a difference, but this whole thing is actually run in a chrooted >> >environment...) It appears that in most instances (and I don't know >> >enough about the packager to know which instances and why), the >> >directories are real directories, but the files inside are symlinks. >> >Specifically: >> > >> >/usr/local/lib/python2.4/site-packages/nose would be a real directory >> >/usr/local/lib/python2.4/site-packages/nose/result.py is a symlink to >> >/base/pkg/Foo/usr/local/lib/python2.4/site-packages/nose/result.py >> > >> >There's a nose-0.9.0-py2.4.egg-info directory next to the nose >> >directory (again, the directory is real but the files inside are >> >symlinks). >> > >> >One more important thing to know about this setup. We have a couple of >> >different packages in /base/pkg, and they both contribute to >> >/usr/local/lib... >> > >> >When you run python, the /baes/pkg... path for the package that >> >contains Python is what shows up in sys.path (not >> >/usr/local/lib/python2.4/site-packages). We created a sitecustomize.py >> >file to add /usr/local/lib/python2.4/site-packages as a sitedir. We're >> >able to import all of the python packages from that directory just >> >fine. But, I wrote a nose plugin that is only found if I explicitly >> >set a PYTHONPATH environment variable to point to >> >/usr/local/lib/python2.4/site-packages. >> > >> > From the Python prompt, if I iter_entry_points, I don't see my plugin >> >without the PYTHONPATH. However, I can require my package and see the >> >entry point via the API. >> > >> >Hopefully that makes it clearer... >> >>Not by much, I'm afraid. You haven't answered these questions: >> >>* Is the plugin on sys.path? > >Yes. Twice it turns out... It first appears in the >/base/pkg/MainPackage/usr/local/lib/python2.4/site-packages location, >and then the symlinked one (mentioned in my earlier message) appears >in /usr/local/lib/python2.4/site-packages which is added to sys.path >via sitecustomize (site.addsitedir). Running "python" from the command >line and looking at sys.path shows both of these locations. > >(Note that Nose itself appears in /base/pkg/DevPackage/... and is then >symlinked into the /usr/local/lib... space, the locations above are >the ones for my Nose plugin.) > >>* How is the plugin installed? Develop? .egg? .egg-info? > >.egg-info > >this may be relevant... the python package is called something like >"foobar" and the egg-info is "FOOBar-1.0-py2.4.egg-info". As I >mentioned, pkg_resources is able to find it. > >>* Where is it installed? > >see above > >>Note that a plugin has to be on sys.path for its entry points to show up, >>so it almost sounds to me like there's no problem here and everything is >>behaving normally. >> >>What would be weird would be if it *did* show in iter_entry_points >>*without* being on sys.path, or if it were on sys.path, but not showing up >>in iter_entry_points. > >Since I was following the single-version-externally-managed model with >an egg-info directory, the egg with the plugin doesn't appear directly >on sys.path. Huh? Above you said it did. Which is it? Maybe you should do this: >>> import pkg_resources >>> print list(pkg_resources.working_set) >>> print sys.path And send me the result. > Here's the kicker, though, if I set the PYTHONPATH >environment variable to /usr/local/lib/python2.4/site-packages the >plugin does show up in iter_entry_points. Doing that has the effect of >putting the /usr/local/lib... symlinked version before the "real" >version in /base/pkg/MainPackage on the sys.path. > >Also, I'm effectively running as root, so there shouldn't be any >permissions issues involved. That's not likely the problem. pkg_resources does a lot of os.realpath()-ing to ensure it's using canonical paths; it's more likely that there's some place where the difference between the "real" path and the version that's on sys.path is causing a problem. Assuming, of course, that there is in fact a problem, which I'm not yet convinced of because your statements above appear inconsistent, although that's probably because you're using more than one definition of what "on sys.path" means. From pje at telecommunity.com Wed Sep 6 19:41:19 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed, 06 Sep 2006 13:41:19 -0400 Subject: [Distutils] problem finding an entry point In-Reply-To: <3f085ecd0609060934w6a3965daod4522e47abdcb34e@mail.gmail.co m> References: <5.1.1.6.0.20060906095352.026382d0@sparrow.telecommunity.com> <7.0.1.0.0.20060905130716.021fb010@telecommunity.com> <5.1.1.6.0.20060906000145.026382e8@unrestrained.com> <5.1.1.6.0.20060906095352.026382d0@sparrow.telecommunity.com> Message-ID: <5.1.1.6.0.20060906133528.0263b2c8@sparrow.telecommunity.com> At 12:34 PM 9/6/2006 -0400, Kevin Dangoor wrote: >On 9/6/06, Phillip J. Eby wrote: >>Maybe you should do this: >> >> >>> import pkg_resources >> >>> print list(pkg_resources.working_set) >> >>> print sys.path >> >>And send me the result. > >OK, here goes: > >>>>import sys >>>>import pkg_resources >>>>print list(pkg_resources.working_set) >[setuptools 0.6c1 >(/usr/local/lib/python2.4/site-packages/setuptools-0.6c1-py2.4.egg), >nose 0.9.0 (/usr/local/lib/python2.4/site-packages)] Aha! It just occurred to me that a bug I thought was fixed in 0.6c1 is actually only fixed in 0.6c2 (not yet released). Could you try installing 0.6.c2dev-r50757, via: easy_install setuptools==dev06 and see if that fixes your problem? I think this is an already-fixed bug. I thought it was limited to case-insensitive filesystems (e.g. Windows), but it looks like it would also apply to symlinks, and produce the results you're seeing. From dangoor at gmail.com Wed Sep 6 19:51:00 2006 From: dangoor at gmail.com (Kevin Dangoor) Date: Wed, 6 Sep 2006 13:51:00 -0400 Subject: [Distutils] problem finding an entry point In-Reply-To: <5.1.1.6.0.20060906133528.0263b2c8@sparrow.telecommunity.com> References: <7.0.1.0.0.20060905130716.021fb010@telecommunity.com> <5.1.1.6.0.20060906000145.026382e8@unrestrained.com> <5.1.1.6.0.20060906095352.026382d0@sparrow.telecommunity.com> <5.1.1.6.0.20060906133528.0263b2c8@sparrow.telecommunity.com> Message-ID: <3f085ecd0609061051p6df715d7i2bbf9c77d970f9aa@mail.gmail.com> On 9/6/06, Phillip J. Eby wrote: > At 12:34 PM 9/6/2006 -0400, Kevin Dangoor wrote: > >On 9/6/06, Phillip J. Eby wrote: > >>Maybe you should do this: > >> > >> >>> import pkg_resources > >> >>> print list(pkg_resources.working_set) > >> >>> print sys.path > >> > >>And send me the result. > > > >OK, here goes: > > > >>>>import sys > >>>>import pkg_resources > >>>>print list(pkg_resources.working_set) > >[setuptools 0.6c1 > >(/usr/local/lib/python2.4/site-packages/setuptools-0.6c1-py2.4.egg), > >nose 0.9.0 (/usr/local/lib/python2.4/site-packages)] > > Aha! It just occurred to me that a bug I thought was fixed in 0.6c1 is > actually only fixed in 0.6c2 (not yet released). > > Could you try installing 0.6.c2dev-r50757, via: > > easy_install setuptools==dev06 > > and see if that fixes your problem? I think this is an already-fixed > bug. I thought it was limited to case-insensitive filesystems (e.g. > Windows), but it looks like it would also apply to symlinks, and produce > the results you're seeing. Yep, that fixes it. Thanks! Kevin From pje at telecommunity.com Thu Sep 7 03:41:18 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed, 06 Sep 2006 21:41:18 -0400 Subject: [Distutils] setuptools 0.6c2 released Message-ID: <5.1.1.6.0.20060906213733.026e1010@sparrow.telecommunity.com> Please upgrade and report any problems promptly; I plan to release this version as 0.6 final if there are no bug reports over the next week or so. Bug fixes since 0.6c1 include: * The ``ez_setup`` module displays the conflicting version of setuptools (and its installation location) when a script requests a version that's not available. * Running ``setup.py develop`` on a setuptools-using project will now install setuptools if needed, instead of only downloading the egg. * Fix a problem with eggs specified directly on ``PYTHONPATH`` on case-insensitive filesystems possibly not showing up in the default working set, due to differing normalizations of ``sys.path`` entries. * Windows script wrappers now support quoted arguments and arguments containing spaces. (Patch contributed by Jim Fulton.) * The ``ez_setup.py`` script now actually works when you put a setuptools ``.egg`` alongside it for bootstrapping an offline machine. * A writable installation directory on ``sys.path`` is no longer required to download and extract a source distribution using ``--editable``. * Generated scripts now use ``-x`` on the ``#!`` line when ``sys.executable`` contains non-ASCII characters, to prevent deprecation warnings about an unspecified encoding when the script is run. From fccoelho at gmail.com Thu Sep 7 17:55:29 2006 From: fccoelho at gmail.com (Flavio Codeco Coelho) Date: Thu, 07 Sep 2006 12:55:29 -0300 Subject: [Distutils] distutils and xmingw Message-ID: <450040F1.4020505@fiocruz.br> Hello, Is it possible to automate building of extensions using xmingw when you do a bdist_wininst? if not, what is the recommended way to cross-compile extension modules on a linux box, targeting windoze? i am particularly interested in f2py extension modules. any help is greatly appreciated. Fl?vio From dangoor at gmail.com Fri Sep 8 15:14:45 2006 From: dangoor at gmail.com (Kevin Dangoor) Date: Fri, 8 Sep 2006 09:14:45 -0400 Subject: [Distutils] [setuptools] best way to create offline install bundles? Message-ID: <3f085ecd0609080614m102df8c2k4c0b4985f2e079e7@mail.gmail.com> I've had quite a few complaints over the months from people who are stuck behind firewalls and can't install TurboGears with easy_install for whatever reason. This problem is somewhat compounded in cases where the user may have a machine that has internet access, but isn't the same platform as their deployment machine so they wouldn't even get the right eggs to deploy with easy_install. What I ultimately want to end up with is a tarball that contains all of the platform independent stuff, and then three tarballs for the platform dependent stuff (win, mac, source). I know about easy_install -zmaxd, and that certainly helps... but 1) it doesn't keep all of the eggs zipped up (because it sitll thinks it's doing an install, instead of just a download) 2) it doesn't help with the three platform dependent parts Is this something zc.buildout can help with? I'm not certain what the best way is to automate this process... Thanks, Kevin -- Kevin Dangoor TurboGears / Zesty News email: kid at blazingthings.com company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com From pje at telecommunity.com Fri Sep 8 19:38:06 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Fri, 08 Sep 2006 13:38:06 -0400 Subject: [Distutils] [setuptools] best way to create offline install bundles? In-Reply-To: <3f085ecd0609080614m102df8c2k4c0b4985f2e079e7@mail.gmail.co m> Message-ID: <5.1.1.6.0.20060908131814.02c66b70@sparrow.telecommunity.com> At 09:14 AM 9/8/2006 -0400, Kevin Dangoor wrote: >I've had quite a few complaints over the months from people who are >stuck behind firewalls and can't install TurboGears with easy_install >for whatever reason. This problem is somewhat compounded in cases >where the user may have a machine that has internet access, but isn't >the same platform as their deployment machine so they wouldn't even >get the right eggs to deploy with easy_install. > >What I ultimately want to end up with is a tarball that contains all >of the platform independent stuff, and then three tarballs for the >platform dependent stuff (win, mac, source). > >I know about easy_install -zmaxd, and that certainly helps... but > >1) it doesn't keep all of the eggs zipped up (because it sitll thinks >it's doing an install, instead of just a download) Huh? -z should force it to never unzip eggs. Are you sure it's doing that? >2) it doesn't help with the three platform dependent parts > >Is this something zc.buildout can help with? I'm not certain what the >best way is to automate this process... If I were in your shoes, I'd certainly take a look at zc.buildout, although I don't know if it has everything you'll need. It would be nice, though, if you ended up with a tool that could be used to build a tarball bundle of any project, not just turbogears. Bonus points if the tarball contains everything in --single-version-externally-managed form, so somebody can just extract it and put it in a directory on PYTHONPATH. ;) (Note that to create the SVEM form of an egg, you just rename the EGG-INFO directory to package-version-pyver-platform.egg-info during extraction; an easy trick using setuptools.archive_util.) Oh, and extra extra bonus points if this thing can become something like "bdist_eggbundle" and was usable via setuptools. Then, you could just run something like "setup.py bdist_eggbundle --platform=XXX" to build one for each platform. :) From jeremy.kloth at 4suite.org Fri Sep 8 20:24:30 2006 From: jeremy.kloth at 4suite.org (Jeremy Kloth) Date: Fri, 8 Sep 2006 12:24:30 -0600 Subject: [Distutils] [setuptools] Bug in setuptools ImpLoader Message-ID: <200609081224.30354.jeremy.kloth@4suite.org> From PEP 302: The load_module() method has a few responsibilities that it must fulfill *before* it runs any code: - If there is an existing module object named 'fullname' in sys.modules, the loader *must* use that existing module. (Otherwise, the reload() builtin will not work correctly.) If a module named 'fullname' does not exist in sys.modules, the loader must create a new module object and add it to sys.modules. (emphasis on must) The current implementation always reloads the module if it exists. This problem exists in both the 0.6 and 0.7 series. Since pkgutil is in Python 2.5, this is an issue there as well. -- Jeremy Kloth http://4suite.org/ From pje at telecommunity.com Fri Sep 8 21:16:07 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Fri, 08 Sep 2006 15:16:07 -0400 Subject: [Distutils] [setuptools] Bug in setuptools ImpLoader In-Reply-To: <200609081224.30354.jeremy.kloth@4suite.org> Message-ID: <5.1.1.6.0.20060908151312.038613b8@sparrow.telecommunity.com> At 12:24 PM 9/8/2006 -0600, Jeremy Kloth wrote: > >From PEP 302: > > The load_module() method has a few responsibilities that it must > fulfill *before* it runs any code: > > - If there is an existing module object named 'fullname' in > sys.modules, the loader *must* use that existing module. > (Otherwise, the reload() builtin will not work correctly.) > If a module named 'fullname' does not exist in sys.modules, > the loader must create a new module object and add it to > sys.modules. >(emphasis on must) > >The current implementation always reloads the module if it exists. Yes, that's the *intent* of the above paragraph. An importer that *doesn't* reload under these circumstances will break the reload() builtin. > This >problem exists in both the 0.6 and 0.7 series. Since pkgutil is in Python >2.5, this is an issue there as well. Unless I've misunderstood you, this is not a problem, it's the correct and intended behavior. When a loader is asked to load a module that's in sys.modules, it's supposed to *reload* it. Otherwise, the reload() builtin won't work. From jeremy.kloth at 4suite.org Fri Sep 8 22:04:00 2006 From: jeremy.kloth at 4suite.org (Jeremy Kloth) Date: Fri, 8 Sep 2006 14:04:00 -0600 Subject: [Distutils] [setuptools] Bug in setuptools ImpLoader In-Reply-To: <5.1.1.6.0.20060908151312.038613b8@sparrow.telecommunity.com> References: <5.1.1.6.0.20060908151312.038613b8@sparrow.telecommunity.com> Message-ID: <200609081404.01344.jeremy.kloth@4suite.org> On Friday 08 September 2006 1:16 pm, Phillip J. Eby wrote: > At 12:24 PM 9/8/2006 -0600, Jeremy Kloth wrote: > > >From PEP 302: > > > > The load_module() method has a few responsibilities that it must > > fulfill *before* it runs any code: > > > > - If there is an existing module object named 'fullname' in > > sys.modules, the loader *must* use that existing module. > > (Otherwise, the reload() builtin will not work correctly.) > > If a module named 'fullname' does not exist in sys.modules, > > the loader must create a new module object and add it to > > sys.modules. > >(emphasis on must) > > > >The current implementation always reloads the module if it exists. > > Yes, that's the *intent* of the above paragraph. An importer that > *doesn't* reload under these circumstances will break the reload() builtin. I read the paragraph as stating that the loader *returns* the module from sys.modules instantly or it would break reload(). After re-reading PEP 302 several times, it becomes clear that the intention is that the module's contents are replaced before returning the module. > > This > >problem exists in both the 0.6 and 0.7 series. Since pkgutil is in Python > >2.5, this is an issue there as well. > > Unless I've misunderstood you, this is not a problem, it's the correct and > intended behavior. When a loader is asked to load a module that's in > sys.modules, it's supposed to *reload* it. Otherwise, the reload() builtin > won't work. It would be worth adding a sentence stating that loader.load_module() is the same as a reload() if the module is already imported (just like the docs for imp.load_module). My confusion, no problem here except for in the code that was expecting my concept for things to work. -- Jeremy Kloth http://4suite.org/ From primco at gmail.com Sat Sep 9 03:47:33 2006 From: primco at gmail.com (David Primmer) Date: Fri, 8 Sep 2006 18:47:33 -0700 Subject: [Distutils] zip eggs not accessible when running setuptools under IIS Message-ID: <275afd030609081847v7347f035v33273f40df9210d0@mail.gmail.com> I've recently figured out how to do wsgi with IIS http://pylonshq.com/project/pylonshq/wiki/ServePylonsWithIIS But I have problem with setuptools. If I have any zip eggs used by the app I'm trying to serve with IIS, I get a dependency not found error. If I remove the .egg zip files and re-download those same packages with --always-unzip, they work fine. There seems to be something preventing zipimport from working. thanks. davep -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20060908/bdd79b01/attachment.html From pje at telecommunity.com Sat Sep 9 03:58:44 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Fri, 08 Sep 2006 21:58:44 -0400 Subject: [Distutils] zip eggs not accessible when running setuptools under IIS In-Reply-To: <275afd030609081847v7347f035v33273f40df9210d0@mail.gmail.co m> Message-ID: <5.1.1.6.0.20060908215630.0268fb18@sparrow.telecommunity.com> At 06:47 PM 9/8/2006 -0700, David Primmer wrote: >I've recently figured out how to do wsgi with IIS >http://pylonshq.com/project/pylonshq/wiki/ServePylonsWithIIS >But I have problem with setuptools. If I have any zip eggs used by the app >I'm trying to serve with IIS, I get a dependency not found error. If I >remove the .egg zip files and re-download those same packages with >--always-unzip, they work fine. There seems to be something preventing >zipimport from working. I'm afraid I haven't got a clue on this one. I can't think of any problem that would cause you to get a DependencyNotFound error with a .egg file that wouldn't do the exact same thing for an .egg directory. There are other kinds of errors I can think of that might happen for one and not the other, but DependencyNotFound isn't one of them. From primco at gmail.com Sat Sep 9 04:07:11 2006 From: primco at gmail.com (primco) Date: Fri, 8 Sep 2006 19:07:11 -0700 (PDT) Subject: [Distutils] [setuptools] best way to create offline install bundles? In-Reply-To: <3f085ecd0609080614m102df8c2k4c0b4985f2e079e7@mail.gmail.com> References: <3f085ecd0609080614m102df8c2k4c0b4985f2e079e7@mail.gmail.com> Message-ID: <6219669.post@talk.nabble.com> I would love this as well, as I'm in a situation where setuptools is forbidden and I need to distribute Python apps like TurboGears and Pylons with loads of dependencies. What do I do to take a snapshot of the distribution and make an RPM of it? And the second part of that, if it is indeed a labor-intensive task, is how can it be automated? This is what Kevin is asking, of course, but I wanted to chime in that Pylons could use this as well and I'd be willing to work on it. davep Kevin Dangoor wrote: > > What I ultimately want to end up with is a tarball that contains all > of the platform independent stuff, and then three tarballs for the > platform dependent stuff (win, mac, source). > > I know about easy_install -zmaxd, and that certainly helps... but > > 1) it doesn't keep all of the eggs zipped up (because it sitll thinks > it's doing an install, instead of just a download) > > 2) it doesn't help with the three platform dependent parts > > Is this something zc.buildout can help with? I'm not certain what the > best way is to automate this process... > -- View this message in context: http://www.nabble.com/-setuptools--best-way-to-create-offline-install-bundles--tf2239029.html#a6219669 Sent from the Python - distutils-sig forum at Nabble.com. From primco at gmail.com Sat Sep 9 04:12:35 2006 From: primco at gmail.com (primco) Date: Fri, 8 Sep 2006 19:12:35 -0700 (PDT) Subject: [Distutils] zip eggs not accessible when running setuptools under IIS In-Reply-To: <5.1.1.6.0.20060908215630.0268fb18@sparrow.telecommunity.com> References: <275afd030609081847v7347f035v33273f40df9210d0@mail.gmail.com> <5.1.1.6.0.20060908215630.0268fb18@sparrow.telecommunity.com> Message-ID: <6219706.post@talk.nabble.com> Sorry, it's a DistributionNotFound error. Here's the end of the traceback. File "c:\python24\lib\site-packages\PasteDeploy-0.9.6-py2.4.egg\paste\deploy\loadwsgi.py", line 270, in _loadegg return loader.get_context(object_type, name, global_conf) File "c:\python24\lib\site-packages\PasteDeploy-0.9.6-py2.4.egg\paste\deploy\loadwsgi.py", line 531, in get_context entry_point, protocol, ep_name = self.find_egg_entry_point( File "c:\python24\lib\site-packages\PasteDeploy-0.9.6-py2.4.egg\paste\deploy\loadwsgi.py", line 552, in find_egg_entry_point pkg_resources.require(self.spec) File "c:\python24\lib\site-packages\setuptools-0.6c2-py2.4.egg\pkg_resources.py", line 585, in require needed = self.resolve(parse_requirements(requirements)) File "c:\python24\lib\site-packages\setuptools-0.6c2-py2.4.egg\pkg_resources.py", line 483, in resolve raise DistributionNotFound(req) # XXX put more info here pkg_resources.DistributionNotFound: Routes>=1.4.1 davep quote author='Phillip J. Eby'> At 06:47 PM 9/8/2006 -0700, David Primmer wrote: >I've recently figured out how to do wsgi with IIS >http://pylonshq.com/project/pylonshq/wiki/ServePylonsWithIIS >But I have problem with setuptools. If I have any zip eggs used by the app >I'm trying to serve with IIS, I get a dependency not found error. If I >remove the .egg zip files and re-download those same packages with >--always-unzip, they work fine. There seems to be something preventing >zipimport from working. I'm afraid I haven't got a clue on this one. I can't think of any problem that would cause you to get a DependencyNotFound error with a .egg file that wouldn't do the exact same thing for an .egg directory. There are other kinds of errors I can think of that might happen for one and not the other, but DependencyNotFound isn't one of them. -- View this message in context: http://www.nabble.com/zip-eggs-not-accessible-when-running-setuptools-under-IIS-tf2242368.html#a6219706 Sent from the Python - distutils-sig forum at Nabble.com. From ronaldoussoren at mac.com Sat Sep 9 16:36:02 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 09 Sep 2006 16:36:02 +0200 Subject: [Distutils] [setuptools] best way to create offline install bundles? In-Reply-To: <6219669.post@talk.nabble.com> References: <3f085ecd0609080614m102df8c2k4c0b4985f2e079e7@mail.gmail.com> <6219669.post@talk.nabble.com> Message-ID: <15983626.1157812562660.JavaMail.ronaldoussoren@mac.com> On Saturday, September 09, 2006, at 04:07AM, primco wrote: > >I would love this as well, as I'm in a situation where setuptools is >forbidden and I need to distribute Python apps like TurboGears and Pylons >with loads of dependencies. Why is setuptools forbidden? Is the the automatic download of packages or is there something else? Setuptools is more than easy_install, it is also a package that has usefull future for packages, such as entrypoints. These are used by TurboGears (and I don't know Pylons), so not installing setuptools at all isn't really an option. Ronald From primco at gmail.com Mon Sep 11 18:34:26 2006 From: primco at gmail.com (primco) Date: Mon, 11 Sep 2006 09:34:26 -0700 (PDT) Subject: [Distutils] [setuptools] best way to create offline install bundles? In-Reply-To: <15983626.1157812562660.JavaMail.ronaldoussoren@mac.com> References: <3f085ecd0609080614m102df8c2k4c0b4985f2e079e7@mail.gmail.com> <6219669.post@talk.nabble.com> <15983626.1157812562660.JavaMail.ronaldoussoren@mac.com> Message-ID: <6250241.post@talk.nabble.com> Setuptools would have to packaged up with TG or Pylons. All programs need to be self contained and can only depend on the standard library in the system wide install. No 'automatic download' would be allowed either. Basically, the whole thing needs to be copied and run. This is a basic feature of Python scripts. It's unfortunate that things have become so complex that this is no longer possible. Ronald Oussoren wrote: > > On Saturday, September 09, 2006, at 04:07AM, primco > wrote: >>I would love this as well, as I'm in a situation where setuptools is >>forbidden and I need to distribute Python apps like TurboGears and Pylons >>with loads of dependencies. > > Why is setuptools forbidden? Is the the automatic download of packages or > is there something else? > > Setuptools is more than easy_install, it is also a package that has > usefull future for packages, such as entrypoints. These are used by > TurboGears (and I don't know Pylons), so not installing setuptools at all > isn't really an option. > -- View this message in context: http://www.nabble.com/-setuptools--best-way-to-create-offline-install-bundles--tf2239029.html#a6250241 Sent from the Python - distutils-sig forum at Nabble.com. From pje at telecommunity.com Mon Sep 11 19:06:38 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Mon, 11 Sep 2006 13:06:38 -0400 Subject: [Distutils] zip eggs not accessible when running setuptools under IIS In-Reply-To: <6219706.post@talk.nabble.com> References: <5.1.1.6.0.20060908215630.0268fb18@sparrow.telecommunity.com> <275afd030609081847v7347f035v33273f40df9210d0@mail.gmail.com> <5.1.1.6.0.20060908215630.0268fb18@sparrow.telecommunity.com> Message-ID: <5.1.1.6.0.20060911130520.035bf878@sparrow.telecommunity.com> At 07:12 PM 9/8/2006 -0700, primco wrote: >Sorry, it's a DistributionNotFound error. Here's the end of the traceback. >... >pkg_resources.DistributionNotFound: Routes>=1.4.1 So this is with a Routes .egg zipfile, but if you extract it to an .egg directory, it works? And if you run it without IIS, it works even with the zipped .egg? Is that a correct summary of the problem? From primco at gmail.com Mon Sep 11 20:12:41 2006 From: primco at gmail.com (primco) Date: Mon, 11 Sep 2006 11:12:41 -0700 (PDT) Subject: [Distutils] zip eggs not accessible when running setuptools under IIS In-Reply-To: <5.1.1.6.0.20060911130520.035bf878@sparrow.telecommunity.com> References: <275afd030609081847v7347f035v33273f40df9210d0@mail.gmail.com> <5.1.1.6.0.20060908215630.0268fb18@sparrow.telecommunity.com> <6219706.post@talk.nabble.com> <5.1.1.6.0.20060911130520.035bf878@sparrow.telecommunity.com> Message-ID: <6251930.post@talk.nabble.com> Phillip J. Eby wrote: > > At 07:12 PM 9/8/2006 -0700, primco wrote: >>Sorry, it's a DistributionNotFound error. Here's the end of the traceback. >>... >>pkg_resources.DistributionNotFound: Routes>=1.4.1 > > So this is with a Routes .egg zipfile, but if you extract it to an .egg > directory, it works? And if you run it without IIS, it works even with > the > zipped .egg? > > Is that a correct summary of the problem? > Yes. This is correct. Mark Hammond is helping me on this as well and we may have a fix that I'm testing right now. from Mark: That one is strange! Inside an IIS6 environment (but not IIS5), that advanced.py sample shows the following error upon reloading: Traceback (most recent call last): File "C:\src\python-2.4-svn\lib\threading.py", line 442, in __bootstrap self.run() File "\\?\C:\src\pywin32\isapi\samples\advanced.py", line 72, in run OSError: [Errno 2] No such file or directory: '\\\\?\\C:\\src\\pywin32\\isapi\\samples\\advanced.py' As you can see, inside the IIS environment, we are getting filenames in the 'unlimited length' style supported by Windows - note the leading '\\?'. The Python (ie, c runtime) file routines don't know how to deal with that. I just took a hacky approach, by changing advanced.py thusly: self.filename = __file__ # IIS6 will give an 'unlimited length' style filename (eg, # '\\?\C:\foo...' - for now, just hack around this. if self.filename.startswith('\\\\?\\'): self.filename = self.filename[4:] However, this is possibly *not* the best fix for this. If you look at sys.path, you will notice that sys.path[0] is a string in this format - it seems more appropriate that we fix that pathname at the source - but I'm out of time to dig any deeper than that right now - but there is a reasonable possibility your egg problem directly relates to this... -- View this message in context: http://www.nabble.com/zip-eggs-not-accessible-when-running-setuptools-under-IIS-tf2242368.html#a6251930 Sent from the Python - distutils-sig forum at Nabble.com. From elvelind at gmail.com Mon Sep 11 21:05:58 2006 From: elvelind at gmail.com (Elvelind Grandin) Date: Mon, 11 Sep 2006 21:05:58 +0200 Subject: [Distutils] setuptools dev > rc. Message-ID: <5035593a0609111205p79952892j4d3910e55980f4ec@mail.gmail.com> I was supriced that the following code returns True. parse_version("0.1dev") > parse_version("0.1rc") A rc release should in my mind be newer then a dev version. Turbogears has a problem with this regarding SQLObject. TG requires SQLObject 0.7.1dev-r1860 but can't use SQLObject 0.7.1rc1 which is a newer release. -- cheers elvelind grandin From primco at gmail.com Mon Sep 11 21:22:10 2006 From: primco at gmail.com (primco) Date: Mon, 11 Sep 2006 12:22:10 -0700 (PDT) Subject: [Distutils] zip eggs not accessible when running setuptools under IIS In-Reply-To: <6251930.post@talk.nabble.com> References: <275afd030609081847v7347f035v33273f40df9210d0@mail.gmail.com> <5.1.1.6.0.20060908215630.0268fb18@sparrow.telecommunity.com> <6219706.post@talk.nabble.com> <5.1.1.6.0.20060911130520.035bf878@sparrow.telecommunity.com> <6251930.post@talk.nabble.com> Message-ID: <6253064.post@talk.nabble.com> Fixing the sys.path[0].startswith('\\\\?\\') Path prefex thing didn't help. I've checked my path and I don't get an error on folder eggs as they get appended to sys.path. However, the zip eggs are not in sys.path and it appears that this is the problem. Once again, doesn't this point to zipimport not working? -- View this message in context: http://www.nabble.com/zip-eggs-not-accessible-when-running-setuptools-under-IIS-tf2242368.html#a6253064 Sent from the Python - distutils-sig forum at Nabble.com. From pje at telecommunity.com Tue Sep 12 00:19:37 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Mon, 11 Sep 2006 18:19:37 -0400 Subject: [Distutils] zip eggs not accessible when running setuptools under IIS In-Reply-To: <6253064.post@talk.nabble.com> References: <6251930.post@talk.nabble.com> <275afd030609081847v7347f035v33273f40df9210d0@mail.gmail.com> <5.1.1.6.0.20060908215630.0268fb18@sparrow.telecommunity.com> <6219706.post@talk.nabble.com> <5.1.1.6.0.20060911130520.035bf878@sparrow.telecommunity.com> <6251930.post@talk.nabble.com> Message-ID: <5.1.1.6.0.20060911181712.02976898@sparrow.telecommunity.com> At 12:22 PM 9/11/2006 -0700, primco wrote: >Fixing the sys.path[0].startswith('\\\\?\\') Path prefex thing didn't help. > >I've checked my path and I don't get an error on folder eggs as they get >appended to sys.path. However, the zip eggs are not in sys.path and it >appears that this is the problem. This is very odd. I keep thinking that maybe IIS isn't importing the 'site' module and thus not processing .pth files (that list the eggs), but if that were the case then the folder eggs would have the same problem. >Once again, doesn't this point to >zipimport not working? Zipimport doesn't put them on sys.path, though. The site module does, by reading them from the .pth file(s). However, this is *also* true for directory eggs. The only thing I can think of is that maybe IIS (or some other part of your stack) has some code that strips sys.path entries that are not directories? That would seem consistent with the nature of the problem. From pje at telecommunity.com Tue Sep 12 01:20:42 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Mon, 11 Sep 2006 19:20:42 -0400 Subject: [Distutils] setuptools dev > rc. In-Reply-To: <5035593a0609111205p79952892j4d3910e55980f4ec@mail.gmail.co m> Message-ID: <5.1.1.6.0.20060911191910.03edceb0@sparrow.telecommunity.com> At 09:05 PM 9/11/2006 +0200, Elvelind Grandin wrote: >I was supriced that the following code returns True. >parse_version("0.1dev") > parse_version("0.1rc") >A rc release should in my mind be newer then a dev version. This is because 'rc' is treated the same as 'c', which in turn is less than 'dev'. From dangoor at gmail.com Tue Sep 12 03:45:32 2006 From: dangoor at gmail.com (Kevin Dangoor) Date: Mon, 11 Sep 2006 21:45:32 -0400 Subject: [Distutils] [setuptools] best way to create offline install bundles? In-Reply-To: <6250241.post@talk.nabble.com> References: <3f085ecd0609080614m102df8c2k4c0b4985f2e079e7@mail.gmail.com> <6219669.post@talk.nabble.com> <15983626.1157812562660.JavaMail.ronaldoussoren@mac.com> <6250241.post@talk.nabble.com> Message-ID: On Sep 11, 2006, at 12:34 PM, primco wrote: > > Setuptools would have to packaged up with TG or Pylons. All > programs need to > be self contained and can only depend on the standard library in > the system > wide install. No 'automatic download' would be allowed either. > Basically, > the whole thing needs to be copied and run. This is a basic feature of > Python scripts. It's unfortunate that things have become so complex > that > this is no longer possible. Actually, this isn't an accurate depiction of the situation. Pre- setuptools, the *only* way to build up a package like TurboGears would have been to take all of the dependencies and dump them into a thirdparty directory, put some massive setup script around it and produce a single, giant tarball. Work would have had to be done to put all of that together. setuptools provides us with a number of great capabilities, and we just need to build up the tool support to make that giant tarball-style of distribution (for offline installs) as easy as the current online installation is. Kevin From antonxx at gmx.de Tue Sep 12 09:10:40 2006 From: antonxx at gmx.de (=?iso-8859-1?Q?=22Anton_M=FCller=22?=) Date: Tue, 12 Sep 2006 09:10:40 +0200 Subject: [Distutils] HOwto download only egg's with setuptools/EasyInstall Message-ID: <20060912071040.222410@gmx.net> Hi, I would like to know if I can use EasyInstall to *download only* an egg file+ all its dependencies in a folder. Concrete example: I would like to download TurboGears egg and all other eggs it needs but without installing it at once. I didn't find a switch (the editable option was not what I needed). Is there some hint or: - do I need to use a downloadmanager (I did it last time but you have to filter out manually what you dont want because on the TurboGears downloadpage there are all old beta's too ... and some eggs are missing here ...) - do I have to write myself a python script analysing the egg header and and and (perhaps it exist already??) A small advice would be nice :-) Anton -- "Feel free" ? 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail From ronaldoussoren at mac.com Tue Sep 12 09:56:47 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 12 Sep 2006 09:56:47 +0200 Subject: [Distutils] [setuptools] best way to create offline install bundles? In-Reply-To: <6250241.post@talk.nabble.com> References: <3f085ecd0609080614m102df8c2k4c0b4985f2e079e7@mail.gmail.com> <6219669.post@talk.nabble.com> <15983626.1157812562660.JavaMail.ronaldoussoren@mac.com> <6250241.post@talk.nabble.com> Message-ID: On Sep 11, 2006, at 6:34 PM, primco wrote: > > Setuptools would have to packaged up with TG or Pylons. All > programs need to > be self contained and can only depend on the standard library in > the system > wide install. No 'automatic download' would be allowed either. > Basically, > the whole thing needs to be copied and run. This is a basic feature of > Python scripts. It's unfortunate that things have become so complex > that > this is no longer possible. Is that ("All programs need to be self contained") some kind of company policy? Not that I disagree, self contained installations can make sysadmin and upgrades a lot easier. Python scripts can still be copied and run, but that hasn't been true for complex, or even less complex, projects for ages. Setuptools makes live easier for the most part: you don't have to bundle (or rewrite) other libraries and still have a pretty simple install because the dependencies are written down in a machine-readable way and a tool (setuptools) can act on that. IIRC both the setuptools documentation and the list archives contain descriptions on how to achieve multiple self-contained python environments. Ronald > > > Ronald Oussoren wrote: >> >> On Saturday, September 09, 2006, at 04:07AM, primco >> >> wrote: >>> I would love this as well, as I'm in a situation where setuptools is >>> forbidden and I need to distribute Python apps like TurboGears >>> and Pylons >>> with loads of dependencies. >> >> Why is setuptools forbidden? Is the the automatic download of >> packages or >> is there something else? >> >> Setuptools is more than easy_install, it is also a package that has >> usefull future for packages, such as entrypoints. These are used by >> TurboGears (and I don't know Pylons), so not installing setuptools >> at all >> isn't really an option. >> > > -- > View this message in context: http://www.nabble.com/-setuptools-- > best-way-to-create-offline-install-bundles--tf2239029.html#a6250241 > Sent from the Python - distutils-sig forum at Nabble.com. > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG at python.org > http://mail.python.org/mailman/listinfo/distutils-sig -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20060912/1eac45bb/attachment-0001.bin From dangoor at gmail.com Tue Sep 12 13:18:56 2006 From: dangoor at gmail.com (Kevin Dangoor) Date: Tue, 12 Sep 2006 07:18:56 -0400 Subject: [Distutils] HOwto download only egg's with setuptools/EasyInstall In-Reply-To: <20060912071040.222410@gmx.net> References: <20060912071040.222410@gmx.net> Message-ID: <373B8868-1AA6-4CFD-A275-73AE7E060371@gmail.com> On Sep 12, 2006, at 3:10 AM, Anton M?ller wrote: > I would like to know if I can use EasyInstall > to *download only* an egg file+ all its > dependencies in a folder. easy_install -zmaxd . TurboGears (don't miss the "." after the d). This will unzip eggs that are not "zip safe". If you look in the distutils-sig archive, I was asking about a better way to do this a couple days ago. It looks like some scripting is needed here. Kevin From jim at zope.com Tue Sep 12 13:37:38 2006 From: jim at zope.com (Jim Fulton) Date: Tue, 12 Sep 2006 07:37:38 -0400 Subject: [Distutils] [setuptools] best way to create offline install bundles? In-Reply-To: <3f085ecd0609080614m102df8c2k4c0b4985f2e079e7@mail.gmail.com> References: <3f085ecd0609080614m102df8c2k4c0b4985f2e079e7@mail.gmail.com> Message-ID: On Sep 8, 2006, at 9:14 AM, Kevin Dangoor wrote: > Is this something zc.buildout can help with? Probably. zc.buildout isn't aimed squarely at this use case. It might work, either as is, or expanded, or some of it's parts might help. Also keep in mind that it is fairly young and rapidly evolving. zc.buildout can certainly assemble a complete installation and it's offline mode should support installation of a shipped buildout that contains all of the eggs needed. In the near future, I'll be adding a missing piece that allows you to nail down all versions used: http://svn.zope.org/zc.buildout/trunk/specifications/repeatable.txt? view=auto Jim > I'm not certain what the > best way is to automate this process... > > Thanks, > Kevin > > -- > Kevin Dangoor > TurboGears / Zesty News > > email: kid at blazingthings.com > company: http://www.BlazingThings.com > blog: http://www.BlueSkyOnMars.com > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG at python.org > http://mail.python.org/mailman/listinfo/distutils-sig -- Jim Fulton mailto:jim at zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org From jim at zope.com Tue Sep 12 15:04:29 2006 From: jim at zope.com (Jim Fulton) Date: Tue, 12 Sep 2006 09:04:29 -0400 Subject: [Distutils] [setuptools] best way to create offline install bundles? In-Reply-To: References: <3f085ecd0609080614m102df8c2k4c0b4985f2e079e7@mail.gmail.com> Message-ID: <6C6593F9-5347-403E-B2E8-9A60E3DB9367@zope.com> On Sep 12, 2006, at 7:37 AM, Jim Fulton wrote: > > On Sep 8, 2006, at 9:14 AM, Kevin Dangoor wrote: >> Is this something zc.buildout can help with? > > Probably. zc.buildout isn't aimed squarely at this use case. It > might work, either as is, or expanded, or some of it's parts might > help. I'll note that we'll need something like this for future Zope releases, which I expect to be eggs based. I would probably leverage zc.buildout for this, so I suppose that this is likely to be a future zc,buildout use case. Jim -- Jim Fulton mailto:jim at zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org From pje at telecommunity.com Tue Sep 12 20:53:05 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Tue, 12 Sep 2006 14:53:05 -0400 Subject: [Distutils] HOwto download only egg's with setuptools/EasyInstall In-Reply-To: <20060912071040.222410@gmx.net> Message-ID: <5.1.1.6.0.20060912145155.03cadc00@sparrow.telecommunity.com> At 09:10 AM 9/12/2006 +0200, Anton M?ller wrote: >Hi, I would like to know if I can use EasyInstall to *download only* an >egg file+ all its dependencies in a folder. Concrete example: I would like >to download TurboGears egg and all other eggs it needs but without >installing it at once. I didn't find a switch (the editable option was not >what I needed). Is there some hint or: - do I need to use a >downloadmanager (I did it last time but you have to filter out manually >what you dont want because on the TurboGears downloadpage there are all >old beta's too ... and some eggs are missing here ...) - do I have to >write myself a python script analysing the egg header and and and >(perhaps it exist already??) A small advice would be nice :-) http://peak.telecommunity.com/DevCenter/EasyInstall#installing-on-un-networked-machines From pje at telecommunity.com Tue Sep 12 21:11:42 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Tue, 12 Sep 2006 15:11:42 -0400 Subject: [Distutils] HOwto download only egg's with setuptools/EasyInstall In-Reply-To: <373B8868-1AA6-4CFD-A275-73AE7E060371@gmail.com> References: <20060912071040.222410@gmx.net> <20060912071040.222410@gmx.net> Message-ID: <5.1.1.6.0.20060912145309.03e66a30@sparrow.telecommunity.com> At 07:18 AM 9/12/2006 -0400, Kevin Dangoor wrote: >On Sep 12, 2006, at 3:10 AM, Anton M?ller wrote: > > > I would like to know if I can use EasyInstall > > to *download only* an egg file+ all its > > dependencies in a folder. > >easy_install -zmaxd . TurboGears > >(don't miss the "." after the d). This will unzip eggs that are not >"zip safe". No, it won't. It's just that if you have an egg on your machine that meets the requirements and it already unzipped, it will get copied to the target directory as-is. But for downloaded eggs, that won't happen, or if it does, it's a bug, in which case please send more details so I can fix it. :) >If you look in the distutils-sig archive, I was asking about a better >way to do this a couple days ago. It looks like some scripting is >needed here. Yep. Maybe something like a "bdist_carton --platform=blah --formats=zip,tgz" command for setuptools would be just the thing. It should install the eggs into a temporary directory in single-version form (i.e. with .egg-info dirs) along with all the packages' scripts. That way, just running any of the scripts would ensure that all the packages were on sys.path, so the script wrappers could be simpler than the standard easy_install-generated ones. Presumably, an "egg carton" tarball like this should also include a script to fix up the #! lines to refer to the appropriate local version of Python. Last, but not least, these tarballs need a naming format that doesn't make easy_install think they're source distributions, by including a Python version (e.g. '-py2.x'). This will make easy_install consider it a "bdist_dumb" package and therefore ignore it when looking for downloads. (Obviously, if you have easy_install, you don't need an egg carton.) Interestingly, an egg cartons doesn't necessarily need to include setuptools, if the contained packages don't use it. The generated scripts don't need it, because they can assume that everything they need is already on sys.path. It's only if an included package actually uses e.g. pkg_resources at runtime that it's necessary, and that could be handled by just bundling pkg_resources.py (and _pkgutil.py, for setuptools 0.7 and Python versions <2.5). This bdist_carton tool would need to be distributed as an add-on for setuptools 0.6, although it could be built-in for 0.7. However, I don't currently have the spare bandwidth to work on this, I'm afraid. From p.f.moore at gmail.com Tue Sep 12 23:19:58 2006 From: p.f.moore at gmail.com (Paul Moore) Date: Tue, 12 Sep 2006 22:19:58 +0100 Subject: [Distutils] Setuptools for Python 2.5 Message-ID: <79990c6b0609121419n30f12a17i13fcc20bd016e822@mail.gmail.com> ez_setup won't install with Python 2.5c1 - presumably, because there isn't a Python 2.5 egg available from the Cheeseshop. I'd have expected it to build from sources in the absence of a suitable egg. Given that it doesn't, how do I build and install setuptools on 2.5c1 (on Windows)? I've downloaded and run setup.py bdist_egg, but how do I get it installed "properly"? I could just build a bdist_wininst and install that, but that's the "old way", and I want to try out the new approach. After I've built the egg, running ez_setup from the setuptools build directory says that setuptools is already installed. Presumably because it's adding the current directory to sys.path, and setuptools *is* in the current directory... I could probably work all this out with some effort from the existing documentation, but that's not my point. I've skimmed the docs, tried ez_setup as described, hit an issue because there's no version-specific build[1] and then hit a wall, as there aren't any pointers as to where to go from here. Can anyone give me some hints? And would it be worth updating the documentation with an explanation of how to handle this (dealing with the lack of a published binary of a package for your specific version of Python - how to find out what you need to build for yourself, where to put things when you have built them, etc etc). I have a sinking feeling that the next thing I'll hit is that once I have setuptools installed, easy_install TurboGears (for example) will also fail from lack of Python 2.5 binaries, and I'll be stuck again... Thanks, Paul. [1] This is particularly frustrating, as setuptools is pure Python, so why do I need a version-specific build? I don't with bdist_wininst.... From pje at telecommunity.com Wed Sep 13 00:03:27 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Tue, 12 Sep 2006 18:03:27 -0400 Subject: [Distutils] Setuptools for Python 2.5 In-Reply-To: <79990c6b0609121419n30f12a17i13fcc20bd016e822@mail.gmail.co m> Message-ID: <5.1.1.6.0.20060912175907.026ec148@sparrow.telecommunity.com> At 10:19 PM 9/12/2006 +0100, Paul Moore wrote: >ez_setup won't install with Python 2.5c1 - presumably, because there >isn't a Python 2.5 egg available from the Cheeseshop. I'd have >expected it to build from sources in the absence of a suitable egg. Actually, that's not the reason. Python 2.5 requires setuptools 0.7a1, which is only available from SVN. >Given that it doesn't, how do I build and install setuptools on 2.5c1 >(on Windows)? I've downloaded and run setup.py bdist_egg, but how do I >get it installed "properly"? I could just build a bdist_wininst and >install that, but that's the "old way", and I want to try out the new >approach. setup.py install. Be sure to use the 0.7a1 version from the trunk. >Can anyone give me some hints? And would it be worth updating the >documentation with an explanation of how to handle this (dealing with >the lack of a published binary of a package for your specific version >of Python - how to find out what you need to build for yourself, where >to put things when you have built them, etc etc). "setup.py install" is the answer to this in the general case. >I have a sinking feeling that the next thing I'll hit is that once I >have setuptools installed, easy_install TurboGears (for example) will >also fail from lack of Python 2.5 binaries, and I'll be stuck again... Probably, unless you set up to use MinGW as your compiler or install the relevant MSVC goodies, so that they can be built from source. >[1] This is particularly frustrating, as setuptools is pure Python, so >why do I need a version-specific build? I don't with bdist_wininst.... One reason why is that setuptools configures its installation differently for different Python versions; there are entry points, for example, that are registered differently for Python 2.3, 2.4, and 2.5. Some packages can have different dependencies, based on Python version too. For example, a package needing ctypes for Python 2.3 or 2.4 shouldn't include the dependency when built for Python 2.5, as ctypes is in the stdlib there. From p.f.moore at gmail.com Wed Sep 13 00:26:36 2006 From: p.f.moore at gmail.com (Paul Moore) Date: Tue, 12 Sep 2006 23:26:36 +0100 Subject: [Distutils] Setuptools for Python 2.5 In-Reply-To: <5.1.1.6.0.20060912175907.026ec148@sparrow.telecommunity.com> References: <5.1.1.6.0.20060912175907.026ec148@sparrow.telecommunity.com> Message-ID: <79990c6b0609121526laec8d45va9de4adeb858633a@mail.gmail.com> On 9/12/06, Phillip J. Eby wrote: > Actually, that's not the reason. Python 2.5 requires setuptools 0.7a1, > which is only available from SVN. Ah. In that case, the error is misleading but at least the solution is straightforward :-) But I built and installed 0.6c2 as a bdist_wininst and things seemed to be sort-of working. What actually goes wrong? Something clearly does, but it's far from obvious... > setup.py install. Be sure to use the 0.7a1 version from the trunk. OK, cool. Does the fact that I can use setup.py install also mean I can just build a bdist_wininst and install that? That was what the single-version-externally-managed format was about, yes? If so, do I miss out on any of the multi-version features by doing things this way? > Probably, unless you set up to use MinGW as your compiler or install the > relevant MSVC goodies, so that they can be built from source. Oh, I have both mingw and (the free version of) MSVC. No problem there - I misread the original problem as implying that it wouldn't build from sources for some reason. > One reason why is that setuptools configures its installation differently > for different Python versions; there are entry points, for example, that > are registered differently for Python 2.3, 2.4, and 2.5. Some packages can > have different dependencies, based on Python version too. For example, a > package needing ctypes for Python 2.3 or 2.4 shouldn't include the > dependency when built for Python 2.5, as ctypes is in the stdlib there. Fair enough. Presumably, as automatic building from source should have worked, this doesn't imply a higher dependency on distributors providing binary eggs than the old approach did. Thanks for the quick reply! Paul. From fuzzyman at voidspace.org.uk Wed Sep 13 00:33:41 2006 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Tue, 12 Sep 2006 23:33:41 +0100 Subject: [Distutils] Setuptools for Python 2.5 In-Reply-To: <79990c6b0609121526laec8d45va9de4adeb858633a@mail.gmail.com> References: <5.1.1.6.0.20060912175907.026ec148@sparrow.telecommunity.com> <79990c6b0609121526laec8d45va9de4adeb858633a@mail.gmail.com> Message-ID: <450735C5.7000706@voidspace.org.uk> Paul Moore wrote: > On 9/12/06, Phillip J. Eby wrote: > >> Actually, that's not the reason. Python 2.5 requires setuptools 0.7a1, >> which is only available from SVN. >> > > Ah. In that case, the error is misleading but at least the solution is > straightforward :-) But I built and installed 0.6c2 as a bdist_wininst > and things seemed to be sort-of working. What actually goes wrong? > Something clearly does, but it's far from obvious... > > >> setup.py install. Be sure to use the 0.7a1 version from the trunk. >> > > OK, cool. Does the fact that I can use setup.py install also mean I > can just build a bdist_wininst and install that? That was what the > single-version-externally-managed format was about, yes? If so, do I > miss out on any of the multi-version features by doing things this > way? > > >> Probably, unless you set up to use MinGW as your compiler or install the >> relevant MSVC goodies, so that they can be built from source. >> > > Oh, I have both mingw and (the free version of) MSVC. No problem there > - I misread the original problem as implying that it wouldn't build > from sources for some reason. > I'm afraid that the *latest* free version of MSVC won't work for compiling extensions. The old one needed certain changes to the distutils configuration to work. distutils also needs configuring to use MinGW by default, but this is very easy. All the best, Fuzzyman http://www.voidspace.org.uk/python/index.shtml From pje at telecommunity.com Wed Sep 13 00:37:27 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Tue, 12 Sep 2006 18:37:27 -0400 Subject: [Distutils] Setuptools for Python 2.5 In-Reply-To: <79990c6b0609121526laec8d45va9de4adeb858633a@mail.gmail.com > References: <5.1.1.6.0.20060912175907.026ec148@sparrow.telecommunity.com> <5.1.1.6.0.20060912175907.026ec148@sparrow.telecommunity.com> Message-ID: <5.1.1.6.0.20060912183146.03a33910@sparrow.telecommunity.com> At 11:26 PM 9/12/2006 +0100, Paul Moore wrote: >On 9/12/06, Phillip J. Eby wrote: >>Actually, that's not the reason. Python 2.5 requires setuptools 0.7a1, >>which is only available from SVN. > >Ah. In that case, the error is misleading but at least the solution is >straightforward :-) But I built and installed 0.6c2 as a bdist_wininst >and things seemed to be sort-of working. What actually goes wrong? >Something clearly does, but it's far from obvious... To be honest, I've completely forgotten at this point. You could skim the "svn log" looking for things related to Python 2.5 if it really matters. :) I just remember that I had to make changes. Some were minor things, like Python 2.5 distutils including its own "upload" command, and others were more substantial, possibly related to other distutils changes or to language changes. >>setup.py install. Be sure to use the 0.7a1 version from the trunk. > >OK, cool. Does the fact that I can use setup.py install also mean I >can just build a bdist_wininst and install that? That was what the >single-version-externally-managed format was about, yes? If so, do I >miss out on any of the multi-version features by doing things this >way? Nope. There are only two things that the SVEM format can't do (besides being uninstalled without a packaging system): 1. It can't include __init__.py for "namespace packages" (packages like peak.* and zope.* that are split across separate distributions). You can have namespace packages, mind you, it's just that you can't include anything in the __init__.py for the package, because it's not installed when a SVEM installation is done. 2. Project-level data files, i.e., resources in the "root" of an egg. There's no way for you to access these resources if a project is installed SVEM, because there's no per-project directory for that stuff to go in. These are both extremely rare things to have in a project. >Fair enough. Presumably, as automatic building from source should have >worked, this doesn't imply a higher dependency on distributors >providing binary eggs than the old approach did. Correct. From jim at zope.com Wed Sep 13 11:49:11 2006 From: jim at zope.com (Jim Fulton) Date: Wed, 13 Sep 2006 05:49:11 -0400 Subject: [Distutils] Is this a reasonable place to discuss zc.buildout? Or do I need to make a separate list? Message-ID: <0657415D-E238-4D11-A70F-7DBB71B7DAB7@zope.com> zc.buildout, http://www.python.org/pypi/zc.buildout, is a system for: - Assembling applications consisting of many programs, Python and otherwise, possibly distributed over muiltiple machines, and for - Managing eggs not installed into system Python installations. Buildout is complementary to easy_install. While easy_install is great for simply installing eggs into a system Python in a highly automated and simple way, buildout is great when: - You need more control over the eggs used, - Different applications need different egg versions, - You are developing an application and don't want to (or can't) modify a Python installation, - You want isolation between different applications sharing a single Python installation. Like easy_install, zc.buildout builds on setuptools. Buildout is still fairly early in it's development and is still evolving. Lots of people are trying it out and providing feedback, which is great. Right now, people send me questions individually. This means that others can't benefit from their questions or their answers. IOW, I need a mailing list. I hate to create yet another mailing list and wonder if this list would be a reasonable place for people to discuss zc.buildout. Would anyone object if I directed zc.buildout discussions here? Jim -- Jim Fulton mailto:jim at zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org From dangoor at gmail.com Wed Sep 13 13:20:06 2006 From: dangoor at gmail.com (Kevin Dangoor) Date: Wed, 13 Sep 2006 07:20:06 -0400 Subject: [Distutils] HOwto download only egg's with setuptools/EasyInstall In-Reply-To: <5.1.1.6.0.20060912145309.03e66a30@sparrow.telecommunity.com> References: <20060912071040.222410@gmx.net> <20060912071040.222410@gmx.net> <5.1.1.6.0.20060912145309.03e66a30@sparrow.telecommunity.com> Message-ID: On Sep 12, 2006, at 3:11 PM, Phillip J. Eby wrote: > At 07:18 AM 9/12/2006 -0400, Kevin Dangoor wrote: > >> (don't miss the "." after the d). This will unzip eggs that are not >> "zip safe". > > No, it won't. It's just that if you have an egg on your machine > that meets the requirements and it already unzipped, it will get > copied to the target directory as-is. But for downloaded eggs, > that won't happen, or if it does, it's a bug, in which case please > send more details so I can fix it. :) Ahh, I hadn't caught that. That's easy enough. > >> If you look in the distutils-sig archive, I was asking about a better >> way to do this a couple days ago. It looks like some scripting is >> needed here. > > Yep. Maybe something like a "bdist_carton --platform=blah -- > formats=zip,tgz" command for setuptools would be just the thing. > It should install the eggs into a temporary directory in single- > version form (i.e. with .egg-info dirs) along with all the > packages' scripts. That way, just running any of the scripts would > ensure that all the packages were on sys.path, so the script > wrappers could be simpler than the standard easy_install-generated > ones. While this certainly sounds useful, it's a bit different from what I'm thinking of. I just want to gather up all of the original .egg files and put them into a tarball. Everything you'd need would be in there, and there could even be a trivial wrapper script that runs ez_setup.py with all of the right options to install those packages. This can give the user all of the easy_install options for installing, rather than being stuck manually dropping the untarred directory into the right place or adding it to their PYTHONPATH.. Kevin From pje at telecommunity.com Wed Sep 13 15:36:16 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed, 13 Sep 2006 09:36:16 -0400 Subject: [Distutils] Is this a reasonable place to discuss zc.buildout? Or do I need to make a separate list? In-Reply-To: <0657415D-E238-4D11-A70F-7DBB71B7DAB7@zope.com> Message-ID: <5.1.1.6.0.20060913092943.026f1720@sparrow.telecommunity.com> At 05:49 AM 9/13/2006 -0400, Jim Fulton wrote: >zc.buildout, http://www.python.org/pypi/zc.buildout, is a system for: > >- Assembling applications consisting of many programs, Python and >otherwise, possibly distributed over muiltiple machines, and for > >- Managing eggs not installed into system Python installations. > >Buildout is complementary to easy_install. While easy_install is >great for simply installing eggs into a system Python in a highly >automated and simple way, buildout is great when: > >- You need more control over the eggs used, > >- Different applications need different egg versions, > >- You are developing an application and don't want to (or can't) >modify a Python installation, > >- You want isolation between different applications sharing a single >Python installation. > >Like easy_install, zc.buildout builds on setuptools. > >Buildout is still fairly early in it's development and is still >evolving. Lots of people are trying it out and providing feedback, >which is great. Right now, people send me questions individually. >This means that others can't benefit from their questions or their >answers. IOW, I need a mailing list. I hate to create yet another >mailing list and wonder if this list would be a reasonable place for >people to discuss zc.buildout. > >Would anyone object if I directed zc.buildout discussions here? I certainly wouldn't object. I actually think that something like buildout's recipe system should eventually become part of -- or replace most build operations of -- setuptools/distutils. ISTM that Buildout is to Python what Ant is to Java or Rake is to Ruby; i.e., a language-idiomatic framework for building things in that language. (I don't count SCons or the various other Python-based build systems I've seen, as they primarily target building non-Python things, whereas zc.buildout is first and foremost a Python build tool.) Anyway, I think I'd ultimately like to see distutils' library and extension build facilities replaced with buildout recipes. The work I've done towards trying to get distutils to build shared libraries and do inter-egg linkage would be a lot less complex if it could be assembled using something like zc.buildout recipes. From jim at zope.com Wed Sep 13 16:14:56 2006 From: jim at zope.com (Jim Fulton) Date: Wed, 13 Sep 2006 10:14:56 -0400 Subject: [Distutils] HOwto download only egg's with setuptools/EasyInstall In-Reply-To: References: <20060912071040.222410@gmx.net> <20060912071040.222410@gmx.net> <5.1.1.6.0.20060912145309.03e66a30@sparrow.telecommunity.com> Message-ID: <32349CA2-BB26-4327-A5A5-AFA839AED12E@zope.com> On Sep 13, 2006, at 7:20 AM, Kevin Dangoor wrote: ... > I just want to gather up all of the original .egg > files and put them into a tarball. Everything you'd need would be in > there, and there could even be a trivial wrapper script that runs > ez_setup.py with all of the right options to install those packages. > This can give the user all of the easy_install options for > installing, rather than being stuck manually dropping the untarred > directory into the right place or adding it to their PYTHONPATH.. Note that you probably want more than this. In particular, you probably want to assemble a bunch of source distributions so that your tar ball is useful on a number of distributions, at least for a source tarball. FWIW, I plan, in the next few days to publish a proposal for providing this functionality in zc.buildout. Jim -- Jim Fulton mailto:jim at zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org From venkatbo at yahoo.com Fri Sep 15 18:07:28 2006 From: venkatbo at yahoo.com (Venkat Bommakanti) Date: Fri, 15 Sep 2006 09:07:28 -0700 (PDT) Subject: [Distutils] distutils 101 question... In-Reply-To: <32349CA2-BB26-4327-A5A5-AFA839AED12E@zope.com> Message-ID: <20060915160728.26464.qmail@web30506.mail.mud.yahoo.com> Hi folks, On i686 Linux, I would like to place my python modules as: /src/py-modules/*.py and use the cmd from : ...base_dir]$ python src/py-modules/setup.py install --prefix=/usr so the .py files and the corresponding compiled .pyc files are at: /usr/lib/python2.4/site-packacges/*.py[c] Its unclear from the documentation, how I could specify the location of the *.py files, ie: /src/py-modules/ in the installation command: ...base_dir]$ python src/py-modules/setup.py install --prefix=/usr I can specify the destination of the module/compiled files, but how do I specify the the path to the .py files. I get the "file not found error". Of course, if I cd to: /src/py-modules/ and run the command, its able to find all the modules listed in setup.py:py_modules[.....] entry. This is one among many other modules (C/py) being built while at the , as part of the build of the entire project... Thanks, /venkat __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From pje at telecommunity.com Fri Sep 15 19:10:53 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Fri, 15 Sep 2006 13:10:53 -0400 Subject: [Distutils] distutils 101 question... In-Reply-To: <20060915160728.26464.qmail@web30506.mail.mud.yahoo.com> References: <32349CA2-BB26-4327-A5A5-AFA839AED12E@zope.com> Message-ID: <5.1.1.6.0.20060915130739.02696f68@sparrow.telecommunity.com> At 09:07 AM 9/15/2006 -0700, Venkat Bommakanti wrote: >Hi folks, > >On i686 Linux, I would like to place my python >modules as: > /src/py-modules/*.py >and use the cmd from : > ...base_dir]$ python src/py-modules/setup.py > install --prefix=/usr FYI, this is not possible. The distutils simply will not work correctly unless you run "setup.py" in the directory where it is located. You can have the modules in 'src/py-modules' if you like, but setup.py would have to reside in base_dir. >so the .py files and the corresponding compiled .pyc >files are at: > /usr/lib/python2.4/site-packacges/*.py[c] > >Its unclear from the documentation, how I could >specify the location of the *.py files, ie: > /src/py-modules/ >in the installation command: > ...base_dir]$ python src/py-modules/setup.py > install --prefix=/usr > >I can specify the destination of the module/compiled >files, but how do I specify the the path to the .py >files. I get the "file not found error". Add this to your setup() call: package_dir={'':'src/py-modules'} And the setup.py will be able to find the modules. You *must*, however, move setup.py to your base_dir, as it will not work otherwise; there are too many places in the distutils where the current directory is assumed to be the same as the setup.py directory. From p.f.moore at gmail.com Fri Sep 15 22:14:55 2006 From: p.f.moore at gmail.com (Paul Moore) Date: Fri, 15 Sep 2006 21:14:55 +0100 Subject: [Distutils] Setuptools for Python 2.5 In-Reply-To: <5.1.1.6.0.20060912175907.026ec148@sparrow.telecommunity.com> References: <5.1.1.6.0.20060912175907.026ec148@sparrow.telecommunity.com> Message-ID: <79990c6b0609151314n79d593aifd20e35a866588@mail.gmail.com> On 9/12/06, Phillip J. Eby wrote: > At 10:19 PM 9/12/2006 +0100, Paul Moore wrote: > >ez_setup won't install with Python 2.5c1 - presumably, because there > >isn't a Python 2.5 egg available from the Cheeseshop. I'd have > >expected it to build from sources in the absence of a suitable egg. > > Actually, that's not the reason. Python 2.5 requires setuptools 0.7a1, > which is only available from SVN. BTW, do you intend to release an "official" 0.7a1 when Python 2.5 comes out? Paul. From pje at telecommunity.com Fri Sep 15 22:26:45 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Fri, 15 Sep 2006 16:26:45 -0400 Subject: [Distutils] Setuptools for Python 2.5 In-Reply-To: <79990c6b0609151314n79d593aifd20e35a866588@mail.gmail.com> References: <5.1.1.6.0.20060912175907.026ec148@sparrow.telecommunity.com> <5.1.1.6.0.20060912175907.026ec148@sparrow.telecommunity.com> Message-ID: <5.1.1.6.0.20060915162558.02696f30@sparrow.telecommunity.com> At 09:14 PM 9/15/2006 +0100, Paul Moore wrote: >On 9/12/06, Phillip J. Eby wrote: >>At 10:19 PM 9/12/2006 +0100, Paul Moore wrote: >> >ez_setup won't install with Python 2.5c1 - presumably, because there >> >isn't a Python 2.5 egg available from the Cheeseshop. I'd have >> >expected it to build from sources in the absence of a suitable egg. >> >>Actually, that's not the reason. Python 2.5 requires setuptools 0.7a1, >>which is only available from SVN. > >BTW, do you intend to release an "official" 0.7a1 when Python 2.5 comes out? That's probably a good idea, now that you mention it. :) I've gotten a little too used to thinking of 2.5 as this far-off thing. :) From ben at groovie.org Sun Sep 17 03:04:26 2006 From: ben at groovie.org (Ben Bangert) Date: Sat, 16 Sep 2006 18:04:26 -0700 Subject: [Distutils] Make ez_setup.py/easy_install $PATH aware Message-ID: This is hopefully a pretty minor fix, and now that I think about it, I'm surprised it hasn't been in setuptools for ages. Some platforms don't have something setup right so that Python scripts are installed deep into Python library directories that definitely aren't in the $PATH. It becomes embarrassing as one tries to write "Install" instructions, and has to keep including a "Do you have any idea where the XXX command is? Try finding it and adding that dir to your path". Or having to tell people not to do anything without making a ~/.pydistutils.cfg file with a install-dir location. So.... couldn't ez_setup.py look at the $PATH present, and notice when the install location is outside of it? Then it could either give a nice big warning about how the scripts its about to install aren't going to be available without re-installing with the package and defining a install-dir for scripts, or adding the path to your $PATH. Surely there ought to be a better solution than blindly copying scripts into locations that will leave users wondering why they can't be run, and it seems like the system for that should be in ez_setup.py as thats a first step to getting the whole setuptools/ easy_install system going. Thanks, Ben From pje at telecommunity.com Sun Sep 17 03:38:33 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Sat, 16 Sep 2006 21:38:33 -0400 Subject: [Distutils] Make ez_setup.py/easy_install $PATH aware In-Reply-To: Message-ID: <5.1.1.6.0.20060916213320.02cb0768@sparrow.telecommunity.com> At 06:04 PM 9/16/2006 -0700, Ben Bangert wrote: >This is hopefully a pretty minor fix, and now that I think about it, >I'm surprised it hasn't been in setuptools for ages. Some platforms >don't have something setup right so that Python scripts are installed >deep into Python library directories that definitely aren't in the >$PATH. > >It becomes embarrassing as one tries to write "Install" instructions, >and has to keep including a "Do you have any idea where the XXX >command is? Try finding it and adding that dir to your path". Or >having to tell people not to do anything without making a >~/.pydistutils.cfg file with a install-dir location. > >So.... couldn't ez_setup.py look at the $PATH present, and notice >when the install location is outside of it? Excellent suggestion, let's add it in 0.7. Patches are of course welcome, or I can just get to it when I get to it. It also needs an option to say "go ahead anyway, I know what I'm doing", or else Jim Fulton will be unhappy. ;-) >Then it could either give >a nice big warning about how the scripts its about to install aren't >going to be available without re-installing with the package and >defining a install-dir for scripts, or adding the path to your $PATH. >Surely there ought to be a better solution than blindly copying >scripts into locations that will leave users wondering why they can't >be run, and it seems like the system for that should be in >ez_setup.py as thats a first step to getting the whole setuptools/ >easy_install system going. By the way, it's easy_install that we actually need to worry about, not ez_setup. ez_setup's only job is to download and run easy_install, which then handles everything from there. So both issues can be handled that way. Windows is probably the main offender, here, however, and I'm not sure there's really a good solution there. I don't think there's a standard $PATH directory that really makes sense for all circumstances, to name just one issue. So, suggestions on what should happen there would be helpful. From jjl at pobox.com Sun Sep 17 14:45:02 2006 From: jjl at pobox.com (John J Lee) Date: Sun, 17 Sep 2006 12:45:02 +0000 (UTC) Subject: [Distutils] Make ez_setup.py/easy_install $PATH aware In-Reply-To: <5.1.1.6.0.20060916213320.02cb0768@sparrow.telecommunity.com> References: <5.1.1.6.0.20060916213320.02cb0768@sparrow.telecommunity.com> Message-ID: On Sat, 16 Sep 2006, Phillip J. Eby wrote: [...] > By the way, it's easy_install that we actually need to worry about, not > ez_setup. ez_setup's only job is to download and run easy_install, which > then handles everything from there. So both issues can be handled that way. > > Windows is probably the main offender, here, however, and I'm not sure > there's really a good solution there. I don't think there's a standard > $PATH directory that really makes sense for all circumstances, to name just > one issue. So, suggestions on what should happen there would be helpful. Perhaps easy_install on Windows should: (I guess step 2. is best done by creating a Windows installer with one of the standard tools (e.g. MSI / msilib)?) 0. Whenever a check is required that executable files are "on the path", call SearchPath(): http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/searchpath.asp 1. Having created a directory for installed Python scripts and set the appropriate registry key at easy_install install time (see step 2), always install Python scripts in that directory. 2. So that easy_install itself can be run without too much user effort, either: a. Always install easy_install.exe to C:\Python2?\Scripts, but warn if it's not on the path. -1 from me, it doesn't seem the "Windows way" to have to have PATH set correctly in order for things to work. b. Create C:\Program Files\PJE\EasyInstall and C:\Program Files\PJE\EasyInstall\Scripts and install easy_install.exe in the latter. Add the appropriate registry key to put the latter "on the path": http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcemain4/html/_wcepb_Search_Path_Registry_Settings.asp (where of course C:\Python2? and C:\Program Files would have to be looked up using the appropriate system call / registry key) Of course, it would be even more Windowsy if somebody then wrote a little GUI that allowed you to search PyPI, select projects and click a button to install them. :-) But the other stuff seems much more useful than point & click stuff: it would "just work" for the Windows easy_install target audience -- who surely know how to use the DOS command line, but who like most of us, are easily put off by complicated installation dances involving setting PATH etc. Windows just doesn't really like PATH -- there's even a fairly short fixed limit on the length of PATH &c. you can type into the dialog box when you're setting up the properties of a shortcut (?) to cmd.exe, so if you want to maintain a couple of different "shell" environments that way and you install too many programs, you're out of luck! John From p.f.moore at gmail.com Sun Sep 17 15:38:00 2006 From: p.f.moore at gmail.com (Paul Moore) Date: Sun, 17 Sep 2006 14:38:00 +0100 Subject: [Distutils] Make ez_setup.py/easy_install $PATH aware In-Reply-To: References: <5.1.1.6.0.20060916213320.02cb0768@sparrow.telecommunity.com> Message-ID: <79990c6b0609170638h66ce8da4w1def4ed62d405625@mail.gmail.com> On 9/17/06, John J Lee wrote: > On Sat, 16 Sep 2006, Phillip J. Eby wrote: > > Windows is probably the main offender, here, however, and I'm not sure > > there's really a good solution there. I don't think there's a standard > > $PATH directory that really makes sense for all circumstances, to name just > > one issue. So, suggestions on what should happen there would be helpful. > > Perhaps easy_install on Windows should: > [...] > 2. So that easy_install itself can be run without too much user effort, > either: > > a. Always install easy_install.exe to C:\Python2?\Scripts, but warn if > it's not on the path. -1 from me, it doesn't seem the "Windows way" > to have to have PATH set correctly in order for things to work. +1 from me to install C:\Pythonxx\Scripts. -1 on the warning. That's the Python standard for where to install scripts/executables (whether they be .py files or .bat files in the normal case - .exe wrappers fit the same model). It's also what easy_install does right now, as far as I can tell. The "Windows way" is basically to not use the command line at all, so there's no established best practice here. Trying to convince yourself there is one will just result in grief (for you, or your users). Don't get me wrong - I am a Windows user myself, and I use the command line a lot. But I don't see any common approach, and I'm used to tweaking my command line environment to work how I want it to. You *can't* make things work "automatically" for me - and I won't thank you for trying. The best you can do is act like a normal Python package - install to C:\Pythonxx\Scripts and leave me to worry about getting it on PATH. I don't think I'm unusual in this (in the context of the limited set of Windows command line users). > b. Create C:\Program Files\PJE\EasyInstall and > C:\Program Files\PJE\EasyInstall\Scripts and install easy_install.exe > in the latter. Add the appropriate registry key to put the latter > "on the path": No, no, no. -1000. That works for GUI apps, where the directory doesn't need to be on PATH, and where there are lots of supporting files along with the EXE. But I really don't want to have a directory on PATH just for one or two executables. > Of course, it would be even more Windowsy if somebody then wrote a little > GUI that allowed you to search PyPI, select projects and click a button to > install them. :-) That *is* more "Windowsy". > But the other stuff seems much more useful than point & > click stuff: it would "just work" for the Windows easy_install target > audience -- who surely know how to use the DOS command line, but who like > most of us, are easily put off by complicated installation dances > involving setting PATH etc. Not sure how true that is. It certainly isn't for me. My idea of "just works" is bdist_wininst. Double click on it, hit "Next" a few times, and you're done. The key benefit of easy_install over this is that it does dependency handling. But it does so at the cost of needing to use the command line. I'm *still* not convinced that the trade-off is right for me (particularly now that PJE has got setuptools recognising "normal" single-version-externally-managed installs). Arguably, if you have Python installed, you're already using C:\PythonXX\Scripts, so it's either on your PATH or you've made other arrangements. So there's no "installation dance" needed. Please note- it was a deliberate decision to have the Python installer *not* to add C:\PythonXX\Scripts to the PATH. You'll need to search the python-dev archives to get the arguments, but they roughly boiled down to a view that the installer should *not* mess with the user's environment. BTW, if you really want to make easy_install.exe available on the command line without needing a PATH entry, you can do what python.exe does: create a registry key HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\easy_install.exe with a single default value of the full pathname for the executable. Then you don't need to muck with the user's PATH at all. For more details, search for "App Paths" in the platform SDK - it gives the full details. Paul. From pje at telecommunity.com Sun Sep 17 16:52:07 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Sun, 17 Sep 2006 10:52:07 -0400 Subject: [Distutils] Make ez_setup.py/easy_install $PATH aware In-Reply-To: <79990c6b0609170638h66ce8da4w1def4ed62d405625@mail.gmail.co m> References: <5.1.1.6.0.20060916213320.02cb0768@sparrow.telecommunity.com> Message-ID: <5.1.1.6.0.20060917103855.026f4288@sparrow.telecommunity.com> At 02:38 PM 9/17/2006 +0100, Paul Moore wrote: >BTW, if you really want to make easy_install.exe available on the >command line without needing a PATH entry, you can do what python.exe >does: create a registry key > >HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\easy_install.exe > >with a single default value of the full pathname for the executable. >Then you don't need to muck with the user's PATH at all. For more >details, search for "App Paths" in the platform SDK - it gives the >full details. Unfortunately, the details it gives are wrong. Neither cmd.exe, command.com, nor bash will find a program registered this way, at least on my Win2K PC. This appears to *only* work for the Start/Run menu. Which isn't a bad start; I imagine that setuptools "GUI scripts" should be installed this way on Windows until/unless we get a way to give them menu entries or icons. A little further investigation reveals that typing "start whatever" in a command window will let you run something that's in "App Paths", *but* it will start in its own window, even if it's a console application. :( So, for console scripts, this still leaves something to be desired. As far as I can tell, *despite* what the MSDN docs say about App Paths, it is strictly a GUI facility and has no effect on command shells. (Interestingly, the lower-level SDK's show why - CreateProcess() ignores app paths, and only ShellExecute takes it into account. That's how I figured out that I could use the "start" command as well as the Start/Run menu option.) From p.f.moore at gmail.com Sun Sep 17 17:29:40 2006 From: p.f.moore at gmail.com (Paul Moore) Date: Sun, 17 Sep 2006 16:29:40 +0100 Subject: [Distutils] Make ez_setup.py/easy_install $PATH aware In-Reply-To: <5.1.1.6.0.20060917103855.026f4288@sparrow.telecommunity.com> References: <5.1.1.6.0.20060916213320.02cb0768@sparrow.telecommunity.com> <5.1.1.6.0.20060917103855.026f4288@sparrow.telecommunity.com> Message-ID: <79990c6b0609170829t43eba6dcn227b3ab8cbe1f8ff@mail.gmail.com> On 9/17/06, Phillip J. Eby wrote: > At 02:38 PM 9/17/2006 +0100, Paul Moore wrote: > >BTW, if you really want to make easy_install.exe available on the > >command line without needing a PATH entry, you can do what python.exe > >does: create a registry key > > > >HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\easy_install.exe [...] > Unfortunately, the details it gives are wrong. Neither cmd.exe, > command.com, nor bash will find a program registered this way, at least on > my Win2K PC. This appears to *only* work for the Start/Run menu. Which > isn't a bad start; I imagine that setuptools "GUI scripts" should be > installed this way on Windows until/unless we get a way to give them menu > entries or icons. [...] > As far as I can tell, *despite* what the MSDN docs say about App Paths, it > is strictly a GUI facility and has no effect on command > shells. (Interestingly, the lower-level SDK's show why - CreateProcess() > ignores app paths, and only ShellExecute takes it into account. That's how > I figured out that I could use the "start" command as well as the Start/Run > menu option.) Sorry about that. I use 4NT, and it never occurred to me that CMD didn't do this as well. Does this mean that on a standard PC, with CMD.exe, typing "python" at he command prompt (with Python installed from the standard installer) doesn't work???!?? [A quick test in VMWare later] Wow! It really doesn't! That seems, well, "less than ideal" :-( How does anyone live with that? I guess command-line Python users on Windows are used to needing to fix up PATH... Thanks for correcting my mistake. Paul. Paul. From pje at telecommunity.com Sun Sep 17 18:37:16 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Sun, 17 Sep 2006 12:37:16 -0400 Subject: [Distutils] Make ez_setup.py/easy_install $PATH aware In-Reply-To: <79990c6b0609170829t43eba6dcn227b3ab8cbe1f8ff@mail.gmail.co m> References: <5.1.1.6.0.20060917103855.026f4288@sparrow.telecommunity.com> <5.1.1.6.0.20060916213320.02cb0768@sparrow.telecommunity.com> <5.1.1.6.0.20060917103855.026f4288@sparrow.telecommunity.com> Message-ID: <5.1.1.6.0.20060917123440.02d25fb8@sparrow.telecommunity.com> At 04:29 PM 9/17/2006 +0100, Paul Moore wrote: >On 9/17/06, Phillip J. Eby wrote: >>At 02:38 PM 9/17/2006 +0100, Paul Moore wrote: >> >BTW, if you really want to make easy_install.exe available on the >> >command line without needing a PATH entry, you can do what python.exe >> >does: create a registry key >> > >> >HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\easy_install.exe >[...] >>Unfortunately, the details it gives are wrong. Neither cmd.exe, >>command.com, nor bash will find a program registered this way, at least on >>my Win2K PC. This appears to *only* work for the Start/Run menu. Which >>isn't a bad start; I imagine that setuptools "GUI scripts" should be >>installed this way on Windows until/unless we get a way to give them menu >>entries or icons. >[...] >>As far as I can tell, *despite* what the MSDN docs say about App Paths, it >>is strictly a GUI facility and has no effect on command >>shells. (Interestingly, the lower-level SDK's show why - CreateProcess() >>ignores app paths, and only ShellExecute takes it into account. That's how >>I figured out that I could use the "start" command as well as the Start/Run >>menu option.) > >Sorry about that. I use 4NT, and it never occurred to me that CMD >didn't do this as well. Does this mean that on a standard PC, with >CMD.exe, typing "python" at he command prompt (with Python installed >from the standard installer) doesn't work???!?? > >[A quick test in VMWare later] > >Wow! It really doesn't! That seems, well, "less than ideal" :-( How >does anyone live with that? I guess command-line Python users on >Windows are used to needing to fix up PATH... Interestingly, I find that you can create an App Paths entry for cmd.exe that adds things to *its* path, but it only works if you start cmd using the "start" command or Start/Run. It doesn't work if you invoke cmd from another shell, nor does it help if you're using a different shell. Ugh. I think getting a workable command-line environment on Windows without end-user customization is an exercise in futility. :( From jjl at pobox.com Sun Sep 17 20:46:19 2006 From: jjl at pobox.com (John J Lee) Date: Sun, 17 Sep 2006 18:46:19 +0000 (UTC) Subject: [Distutils] Make ez_setup.py/easy_install $PATH aware In-Reply-To: <5.1.1.6.0.20060917103855.026f4288@sparrow.telecommunity.com> References: <5.1.1.6.0.20060916213320.02cb0768@sparrow.telecommunity.com> <5.1.1.6.0.20060917103855.026f4288@sparrow.telecommunity.com> Message-ID: On Sun, 17 Sep 2006, Phillip J. Eby wrote: [...] > Unfortunately, the details it gives are wrong. Neither cmd.exe, command.com, > nor bash will find a program registered this way, at least on my Win2K PC. [...] > A little further investigation reveals that typing "start whatever" in a > command window will let you run something that's in "App Paths", *but* it > will start in its own window, even if it's a console application. :( > > So, for console scripts, this still leaves something to be desired. [...] Crap. I withdraw my proposal. (except for the part about having a little Tkinter GUI to allow you to install projects via a PyPI query and point and click -- that would still be nice, especially wrt being friendly to new Python / easy_install users) John From fuzzyman at voidspace.org.uk Sun Sep 17 21:00:47 2006 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sun, 17 Sep 2006 20:00:47 +0100 Subject: [Distutils] Make ez_setup.py/easy_install $PATH aware In-Reply-To: References: <5.1.1.6.0.20060916213320.02cb0768@sparrow.telecommunity.com> <5.1.1.6.0.20060917103855.026f4288@sparrow.telecommunity.com> Message-ID: <450D9B5F.6080404@voidspace.org.uk> John J Lee wrote: > On Sun, 17 Sep 2006, Phillip J. Eby wrote: > [...] > >> Unfortunately, the details it gives are wrong. Neither cmd.exe, command.com, >> nor bash will find a program registered this way, at least on my Win2K PC. >> > [...] > >> A little further investigation reveals that typing "start whatever" in a >> command window will let you run something that's in "App Paths", *but* it >> will start in its own window, even if it's a console application. :( >> >> So, for console scripts, this still leaves something to be desired. >> > [...] > > Crap. I withdraw my proposal. > > (except for the part about having a little Tkinter GUI to allow you to > install projects via a PyPI query and point and click -- that would still > be nice, especially wrt being friendly to new Python / easy_install users) > This would seem to be an excellent basis : http://www.boddie.org.uk/david/Projects/Python/PyPI-Browser/ (except for the license.) Fuzzyman http://www.voidspace.org.uk/python/index.shtml > > John > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG at python.org > http://mail.python.org/mailman/listinfo/distutils-sig > > > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.12.4/449 - Release Date: 15/09/2006 From p.f.moore at gmail.com Sun Sep 17 23:32:22 2006 From: p.f.moore at gmail.com (Paul Moore) Date: Sun, 17 Sep 2006 22:32:22 +0100 Subject: [Distutils] Make ez_setup.py/easy_install $PATH aware In-Reply-To: <5.1.1.6.0.20060917123440.02d25fb8@sparrow.telecommunity.com> References: <5.1.1.6.0.20060916213320.02cb0768@sparrow.telecommunity.com> <5.1.1.6.0.20060917103855.026f4288@sparrow.telecommunity.com> <5.1.1.6.0.20060917123440.02d25fb8@sparrow.telecommunity.com> Message-ID: <79990c6b0609171432m345c661aj9b18bd98e9985961@mail.gmail.com> On 9/17/06, Phillip J. Eby wrote: > I think getting a workable command-line environment on Windows without > end-user customization is an exercise in futility. :( Agreed. That's where I came in :-) Paul From jjl at pobox.com Sun Sep 17 23:50:14 2006 From: jjl at pobox.com (John J Lee) Date: Sun, 17 Sep 2006 21:50:14 +0000 (UTC) Subject: [Distutils] Make ez_setup.py/easy_install $PATH aware In-Reply-To: <450D9B5F.6080404@voidspace.org.uk> References: <5.1.1.6.0.20060916213320.02cb0768@sparrow.telecommunity.com> <5.1.1.6.0.20060917103855.026f4288@sparrow.telecommunity.com> <450D9B5F.6080404@voidspace.org.uk> Message-ID: On Sun, 17 Sep 2006, Michael Foord wrote: [...] >> (except for the part about having a little Tkinter GUI to allow you to >> install projects via a PyPI query and point and click -- that would still >> be nice, especially wrt being friendly to new Python / easy_install users) >> > This would seem to be an excellent basis : > > http://www.boddie.org.uk/david/Projects/Python/PyPI-Browser/ > > (except for the license.) and the GUI toolkit: a Tkinter-based GUI would be more appropriate for distribution with easy_install (since Tkinter is included with the default CPython Windows install). I suppose these days Windows Forms (or WinFX / WPF?) and Swing versions would also be good :-/ (What happened to anygui?) John From m at tacker.org Mon Sep 18 12:50:49 2006 From: m at tacker.org (Markus Tacker) Date: Mon, 18 Sep 2006 12:50:49 +0200 Subject: [Distutils] AttributeError: 'NoneType' object has no attribute 'group' in get_svn_revision Message-ID: <23620bd60609180350o31a99e25n9be66b1802fc1aa7@mail.gmail.com> Hoi, while trying to build the webadmin plugin for trac setuptools die with this error: # python setup.py install running install running bdist_egg Traceback (most recent call last): File "setup.py", line 34, in ? entry_points = { File "/usr/lib/python2.4/distutils/core.py", line 149, in setup dist.run_commands() File "/usr/lib/python2.4/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/usr/lib/python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/usr/lib/python2.4/site-packages/setuptools-0.6c2-py2.4.egg/setuptools/command/install.py", line 76, in run self.do_egg_install() File "/usr/lib/python2.4/site-packages/setuptools-0.6c2-py2.4.egg/setuptools/command/install.py", line 92, in do_egg_install self.run_command('bdist_egg') File "/usr/lib/python2.4/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/usr/lib/python2.4/distutils/dist.py", line 965, in run_command cmd_obj.ensure_finalized() File "/usr/lib/python2.4/distutils/cmd.py", line 117, in ensure_finalized self.finalize_options() File "/usr/lib/python2.4/site-packages/setuptools-0.6c2-py2.4.egg/setuptools/command/bdist_egg.py", line 94, in finalize_options ei_cmd = self.ei_cmd = self.get_finalized_command("egg_info") File "/usr/lib/python2.4/distutils/cmd.py", line 319, in get_finalized_command cmd_obj.ensure_finalized() File "/usr/lib/python2.4/distutils/cmd.py", line 117, in ensure_finalized self.finalize_options() File "/usr/lib/python2.4/site-packages/setuptools-0.6c2-py2.4.egg/setuptools/command/egg_info.py", line 85, in finalize_options self.vtags = self.tags() File "/usr/lib/python2.4/site-packages/setuptools-0.6c2-py2.4.egg/setuptools/command/egg_info.py", line 179, in tags ): version += '-r%s' % self.get_svn_revision() File "/usr/lib/python2.4/site-packages/setuptools-0.6c2-py2.4.egg/setuptools/command/egg_info.py", line 196, in get_svn_revision dirurl = urlre.search(data).group(1) # get repository URL AttributeError: 'NoneType' object has no attribute 'group' Python 2.4.3 SVN Version 1.4.0 (r21228) Any ideas? -- mit freundlichen Gr??en email ~ m at tacker.org Markus Tacker url ~ http://m.tacker.org/ icq ~ 91709561 From pje at telecommunity.com Mon Sep 18 16:19:57 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Mon, 18 Sep 2006 10:19:57 -0400 Subject: [Distutils] AttributeError: 'NoneType' object has no attribute 'group' in get_svn_revision In-Reply-To: <23620bd60609180350o31a99e25n9be66b1802fc1aa7@mail.gmail.co m> Message-ID: <5.1.1.6.0.20060918101759.026f54f8@sparrow.telecommunity.com> At 12:50 PM 9/18/2006 +0200, Markus Tacker wrote: >Hoi, while trying to build the webadmin plugin for trac setuptools die >with this error: The version of setuptools you're using doesn't support Subversion 1.4; you need to upgrade to the latest version using either: easy_install setuptools==dev or easy_install setuptools==dev06 Depending on whether you want the 0.7a1 trunk or an early version of 0.6c3. I just added support for Subversion 1.4 this weekend, along with a fix so that future Subversion working copy format changes won't cause errors. From m at tacker.org Mon Sep 18 16:41:26 2006 From: m at tacker.org (Markus Tacker) Date: Mon, 18 Sep 2006 16:41:26 +0200 Subject: [Distutils] AttributeError: 'NoneType' object has no attribute 'group' in get_svn_revision In-Reply-To: <5.1.1.6.0.20060918101759.026f54f8@sparrow.telecommunity.com> References: <5.1.1.6.0.20060918101759.026f54f8@sparrow.telecommunity.com> Message-ID: <23620bd60609180741m16322eb7ib29013f44133f900@mail.gmail.com> Hoi, On 9/18/06, Phillip J. Eby wrote: > The version of setuptools you're using doesn't support Subversion 1.4; you > need to upgrade to the latest version using either: this gives me similar errors: # python ez_setup.py setuptools==dev Downloading http://cheeseshop.python.org/packages/2.4/s/setuptools/setuptools-0.6c2-py2.4.egg Searching for setuptools==dev Reading http://www.python.org/pypi/setuptools/ Reading http://peak.telecommunity.com/DevCenter/setuptools Reading http://www.python.org/pypi/setuptools/0.6c2 Best match: setuptools dev Downloading http://svn.python.org/projects/sandbox/trunk/setuptools/#egg=setuptools-dev Doing subversion checkout from http://svn.python.org/projects/sandbox/trunk/setuptools/ to /tmp/easy_install-7lz6Ft/setuptools Processing setuptools Running setup.py -q bdist_egg --dist-dir /tmp/easy_install-7lz6Ft/setuptools/egg-dist-tmp-dnMMUT Traceback (most recent call last): File "ez_setup.py", line 214, in ? main(sys.argv[1:]) File "ez_setup.py", line 149, in main return main(list(argv)+[egg]) # we're done here File "/opt/setuptools/setuptools-0.6c2-py2.4.egg/setuptools/command/easy_install.py", line 1588, in main File "/opt/setuptools/setuptools-0.6c2-py2.4.egg/setuptools/command/easy_install.py", line 1577, in with_ei_usage File "/opt/setuptools/setuptools-0.6c2-py2.4.egg/setuptools/command/easy_install.py", line 1591, in File "/usr/lib/python2.4/distutils/core.py", line 149, in setup dist.run_commands() File "/usr/lib/python2.4/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/usr/lib/python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/opt/setuptools/setuptools-0.6c2-py2.4.egg/setuptools/command/easy_install.py", line 211, in run File "/opt/setuptools/setuptools-0.6c2-py2.4.egg/setuptools/command/easy_install.py", line 446, in easy_install File "/opt/setuptools/setuptools-0.6c2-py2.4.egg/setuptools/command/easy_install.py", line 471, in install_item File "/opt/setuptools/setuptools-0.6c2-py2.4.egg/setuptools/command/easy_install.py", line 655, in install_eggs File "/opt/setuptools/setuptools-0.6c2-py2.4.egg/setuptools/command/easy_install.py", line 930, in build_and_install File "/opt/setuptools/setuptools-0.6c2-py2.4.egg/setuptools/command/easy_install.py", line 919, in run_setup File "/opt/setuptools/setuptools-0.6c2-py2.4.egg/setuptools/sandbox.py", line 26, in run_setup File "/opt/setuptools/setuptools-0.6c2-py2.4.egg/setuptools/sandbox.py", line 63, in run File "/opt/setuptools/setuptools-0.6c2-py2.4.egg/setuptools/sandbox.py", line 29, in File "setup.py", line 94, in ? File "/usr/lib/python2.4/distutils/core.py", line 149, in setup dist.run_commands() File "/usr/lib/python2.4/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/usr/lib/python2.4/distutils/dist.py", line 965, in run_command cmd_obj.ensure_finalized() File "/usr/lib/python2.4/distutils/cmd.py", line 117, in ensure_finalized self.finalize_options() File "/opt/setuptools/setuptools-0.6c2-py2.4.egg/setuptools/command/bdist_egg.py", line 94, in finalize_options File "/usr/lib/python2.4/distutils/cmd.py", line 319, in get_finalized_command cmd_obj.ensure_finalized() File "/usr/lib/python2.4/distutils/cmd.py", line 117, in ensure_finalized self.finalize_options() File "/opt/setuptools/setuptools-0.6c2-py2.4.egg/setuptools/command/egg_info.py", line 85, in finalize_options File "/opt/setuptools/setuptools-0.6c2-py2.4.egg/setuptools/command/egg_info.py", line 179, in tags File "/opt/setuptools/setuptools-0.6c2-py2.4.egg/setuptools/command/egg_info.py", line 196, in get_svn_revision AttributeError: 'NoneType' object has no attribute 'group' -- mit freundlichen Gr??en email ~ m at tacker.org Markus Tacker url ~ http://m.tacker.org/ icq ~ 91709561 From pje at telecommunity.com Mon Sep 18 16:48:54 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Mon, 18 Sep 2006 10:48:54 -0400 Subject: [Distutils] AttributeError: 'NoneType' object has no attribute 'group' in get_svn_revision In-Reply-To: <23620bd60609180741m16322eb7ib29013f44133f900@mail.gmail.co m> References: <5.1.1.6.0.20060918101759.026f54f8@sparrow.telecommunity.com> <5.1.1.6.0.20060918101759.026f54f8@sparrow.telecommunity.com> Message-ID: <5.1.1.6.0.20060918104600.0270a650@sparrow.telecommunity.com> At 04:41 PM 9/18/2006 +0200, Markus Tacker wrote: >Hoi, On 9/18/06, Phillip J. Eby wrote: > The >version of setuptools you're using doesn't support Subversion 1.4; you > >need to upgrade to the latest version using either: this gives me similar >errors: Hm. Okay, do this: easy_install -eb. setuptools==dev06 This will create a setuptools subdirectory in the current directory. Then do: cd setuptools python2.4 setup.py install The problem that you're having is that your current version of easy_install is using the setuptools version that doesn't work right with Subversion 1.4. The above approach should work around the problem by only checking out the code, not building it. The second step then builds it using the *new* version of setuptools, which doesn't have the problem. Sorry about that. From esj at harvee.org Mon Sep 18 19:42:56 2006 From: esj at harvee.org (Eric S. Johansson) Date: Mon, 18 Sep 2006 13:42:56 -0400 Subject: [Distutils] compiling C wrappers from distutils Message-ID: I haven't seen any documentation on this or if I have, I didn't recognize it. I need to compile some setgid wrappers which call Python programs. is there a recommended way for compiling then deploying these wrappers as part of a setup.py file? Many thanks for any pointers, ---eric From sjmachin at lexicon.net Tue Sep 19 07:10:02 2006 From: sjmachin at lexicon.net (John Machin) Date: Tue, 19 Sep 2006 15:10:02 +1000 Subject: [Distutils] setuptools: egg traceback seems not very informative Message-ID: <450F7BAA.1040005@lexicon.net> Hello all, Example below, with distutils setup of same package under Python 2.5 for comparison. Two problems: (1) Path of source file is part only of the path from the *development* machine and gives no clue as to where the egg is located on the runtime machine nor what Python version nor what package version -- all of which is in the name of the egg!!! (2) The source line is not shown. Can I work around this? Is this recognised as a problem? Are there plans to enhance any of this? Cheers, John | C:\xlrdtest>python | Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 | Type "help", "copyright", "credits" or "license" for more information. | >>> import xlrd | >>> xlrd.__VERSION__ | '0.6.0a3' | >>> xlrd.__file__ | 'c:\\python24\\lib\\site-packages\\xlrd-0.6.0a3-py2.4.egg\\xlrd\\__init__.pyc' | >>> xlrd.open_workbook('nosuchfile') | Traceback (most recent call last): | File "", line 1, in ? | File "build\bdist.win32\egg\xlrd\__init__.py", line 173, in open_workbook | File "build\bdist.win32\egg\xlrd\__init__.py", line 444, in __init__ | IOError: [Errno 2] No such file or directory: 'nosuchfile' | >>> ^Z | | | C:\xlrdtest>\python25\python | Python 2.5c2 (r25c2:51859, Sep 12 2006, 09:33:52) [MSC v.1310 32 bit (Intel)] on | win32 | Type "help", "copyright", "credits" or "license" for more information. | >>> import xlrd | >>> xlrd.__VERSION__ | '0.6.0a3' | >>> xlrd.__file__ | 'C:\\python25\\lib\\site-packages\\xlrd\\__init__.pyc' | >>> xlrd.open_workbook('nosuchfile') | Traceback (most recent call last): | File "", line 1, in | File "C:\Python25\Lib\site-packages\xlrd\__init__.py", line 173, in open_workb | ook | encoding_override=encoding_override, | File "C:\Python25\Lib\site-packages\xlrd\__init__.py", line 444, in __init__ | f = open(filename, open_mode) | IOError: [Errno 2] No such file or directory: 'nosuchfile' | >>> | From faassen at infrae.com Tue Sep 19 11:43:15 2006 From: faassen at infrae.com (Martijn Faassen) Date: Tue, 19 Sep 2006 11:43:15 +0200 Subject: [Distutils] should setuptools be an implicit dependency of every egg? Message-ID: <450FBBB3.6070406@infrae.com> Hi there, Normally setuptools is installed system-wide. When you install an egg using easy_install, the egg itself can count on setuptools being available, and use for instance its resource management API and namespace package marking facility. It therefore is unnecessary to users to mark setuptools as a dependency to their eggs in setup.py. Since it's unnecessary, it'll just not be done. This works fine in the case of system-wide installation of setuptools, but when installing eggs locally, such as in Buildout, this can lead to problems. Buildout makes sure that only eggs that are dependencies are importable when starting up a script. An egg that is depending on setuptools implicitly will therefore not have access to setuptools facilities. Telling everybody who makes eggs that use setuptools to please take Buildout into account and include setuptools as an explicit dependency in setup.py seems like a hopeless exercise, as things will just plain work for most egg users and developers, at least until the possible eventuality of Buildout reaching critical mass in the community. What would work for Buildout, and as far as I can see does no harm to everybody else, is to make setuptools an implicit dependency of all eggs. It won't affect anyone else (but for a hopefully tiny performance impact) as setuptools is definitely available on the system when installing the egg through easy_install anyway. So, would this be something that could be added to setuptools? Regards, Martijn From bob at redivi.com Tue Sep 19 12:15:31 2006 From: bob at redivi.com (Bob Ippolito) Date: Tue, 19 Sep 2006 03:15:31 -0700 Subject: [Distutils] should setuptools be an implicit dependency of every egg? In-Reply-To: <450FBBB3.6070406@infrae.com> References: <450FBBB3.6070406@infrae.com> Message-ID: <6a36e7290609190315t1d61274duc5d94ff097369507@mail.gmail.com> On 9/19/06, Martijn Faassen wrote: > > Normally setuptools is installed system-wide. When you install an egg > using easy_install, the egg itself can count on setuptools being > available, and use for instance its resource management API and > namespace package marking facility. It therefore is unnecessary to users > to mark setuptools as a dependency to their eggs in setup.py. Since it's > unnecessary, it'll just not be done. > .. > So, would this be something that could be added to setuptools? +1 -bob From jim at zope.com Tue Sep 19 14:11:41 2006 From: jim at zope.com (Jim Fulton) Date: Tue, 19 Sep 2006 08:11:41 -0400 Subject: [Distutils] should setuptools be an implicit dependency of every egg? In-Reply-To: <450FBBB3.6070406@infrae.com> References: <450FBBB3.6070406@infrae.com> Message-ID: <361B82FA-2AF8-47EB-8D82-C3758334F653@zope.com> On Sep 19, 2006, at 5:43 AM, Martijn Faassen wrote: > Hi there, > > Normally setuptools is installed system-wide. When you install an egg > using easy_install, the egg itself can count on setuptools being > available, and use for instance its resource management API and > namespace package marking facility. It therefore is unnecessary to > users > to mark setuptools as a dependency to their eggs in setup.py. Since > it's > unnecessary, it'll just not be done. > > This works fine in the case of system-wide installation of setuptools, > but when installing eggs locally, such as in Buildout, this can > lead to > problems. Buildout makes sure that only eggs that are dependencies are > importable when starting up a script. An egg that is depending on > setuptools implicitly will therefore not have access to setuptools > facilities. Note that the scripts generated by zc.buildout don't use pkg_resources to determine the eggs to be loaded at run time. The needed eggs are computed at install time and their locations are written into the script. If a script doesn't need setuptools (as determined from egg dependencies), then setuptools is not included in the script path. Unfortunately, many eggs that do import pkg_resurces or setuptools don't bother to list setuptools as a dependency. > Telling everybody who makes eggs that use setuptools to please take > Buildout into account and include setuptools as an explicit dependency > in setup.py seems like a hopeless exercise, as things will just plain > work for most egg users and developers, at least until the possible > eventuality of Buildout reaching critical mass in the community. I would put this differently. I would ask people to be accurate about their dependencies rather than implicitly assuming that setuptools is around. > What would work for Buildout, and as far as I can see does no harm to > everybody else, is to make setuptools an implicit dependency of all > eggs. It won't affect anyone else (but for a hopefully tiny > performance > impact) as setuptools is definitely available on the system when > installing the egg through easy_install anyway. setuptools is avaialble to buildout, because buildout uses it. The small downsides of making setuptools an implicit dependency of every egg is that: - setuptools will be included in the path of every script even when not needed. This probably has a tiny performance penalty. - setuptools will be downloaded an installed in some cases where it isn't needed. zc.buildout can install scripts for versions of Python other than that used to run zc.buildout. For example, you could run zc.buildout with Python2.4 and asl it to install a Python 2.3 script. We actually do this on occasion when we use buildout to install applications that don't support Python 2.4. These applications generally don't use setuptools, but I might still have to install setuptools just because we consider every egg, implicitly to depending on it. These downsides are, in practice, pretty minor. My main objection is that I don't like encouraging people to be sloppy about dependencies. The counter argument, of course, is that the standard library is an implicit dependency and we are behaving as if setuptools is part of the standard library. > So, would this be something that could be added to setuptools? Nothing would have to change in setuptools. If we agree that setuptools is an implicit requirement of every egg, even if the egg never imports anything from the setuptools egg, then I'll modify zc.buildout to include setuptools in the path of every script. Jim -- Jim Fulton mailto:jim at zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org From pje at telecommunity.com Tue Sep 19 16:18:26 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Tue, 19 Sep 2006 10:18:26 -0400 Subject: [Distutils] setuptools: egg traceback seems not very informative In-Reply-To: <450F7BAA.1040005@lexicon.net> Message-ID: <5.1.1.6.0.20060919101203.031ea5e8@sparrow.telecommunity.com> At 03:10 PM 9/19/2006 +1000, John Machin wrote: >Hello all, >Example below, with distutils setup of same package under Python 2.5 for >comparison. Two problems: >(1) Path of source file is part only of the path from the *development* >machine and gives no clue as to where the egg is located on the runtime >machine nor what Python version nor what package version -- all of which >is in the name of the egg!!! >(2) The source line is not shown. >Can I work around this? Is this recognised as a problem? Are there plans >to enhance any of this? >Cheers, >John The problem is actually fixed in Python 2.5; the issue is that the 'inspect' and 'traceback' modules in older Python versions do not support zipped modules well. I don't know if the fixes can be meaningfully backported, since they involve changes to fairly core stdlib modules, especially traceback and linecache. From pje at telecommunity.com Tue Sep 19 17:51:40 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Tue, 19 Sep 2006 11:51:40 -0400 Subject: [Distutils] Sourceforge mirrors, again Message-ID: <5.1.1.6.0.20060919114131.026ee060@sparrow.telecommunity.com> Well, it looks like Sourceforge has found yet another way to mess with easy_install's ability to download from their mirrors. :( Specifically, they are not keeping the dl.sourceforge.net "A" list up-to-date, so easy_install's attempts to just use simple round-robin DNS aren't always working. Several IPs in the round robin "A" list are not responding, and some new mirrors haven't been added to it. At this rate, the current approach will become unusable in a relatively short timeframe. :( It seems as though there is no way to auto-discover the mirrors themselves; I had hoped that perhaps a zone transfer on the dl.sourceforge.net zone might work to obtain a list of the actual mirrors, but I haven't been able to successfully obtain one. What I'm wondering at this point is if perhaps the only sane thing to do is to publish our own mirror list via DNS, so that at least when there's a problem it can still be fixed. The idea would be to replace easy_install's current DNS lookup of 'dl.sourceforge.net' IPs with something like 'dl.sfmirrors.telecommunity.com' (for example). Anybody have any thoughts on this? From tseaver at palladion.com Tue Sep 19 19:21:26 2006 From: tseaver at palladion.com (Tres Seaver) Date: Tue, 19 Sep 2006 13:21:26 -0400 Subject: [Distutils] should setuptools be an implicit dependency of every egg? In-Reply-To: <361B82FA-2AF8-47EB-8D82-C3758334F653@zope.com> References: <450FBBB3.6070406@infrae.com> <361B82FA-2AF8-47EB-8D82-C3758334F653@zope.com> Message-ID: <45102716.7020800@palladion.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jim Fulton wrote: > These downsides are, in practice, pretty minor. My main objection is > that I don't like encouraging people to be sloppy about > dependencies. The counter argument, of course, is that the standard > library is an implicit dependency and we are behaving as if > setuptools is part of the standard library. Perhaps we need a lint-like utility ('candle.py', perhaps :) which examines a given egg, looking for issues such as imports from packages which are not in a path synthesized from the egg's dependencies? Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver at palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFECcW+gerLs4ltQ4RAuLaAKDOUslXaXEkF6Wfm1ZuQNjvCZvtzACfQBPU MjwS1kpOSpPzJPw6UWyiXaY= =EMPe -----END PGP SIGNATURE----- From matt at matt-good.net Tue Sep 19 20:59:11 2006 From: matt at matt-good.net (Matt Good) Date: Tue, 19 Sep 2006 14:59:11 -0400 Subject: [Distutils] easy_install doesn't recognize valid distutils Windows installers Message-ID: <1158692351.6014.56.camel@nny> On Windows "easy_install trac" fails with the error: "trac-0.10b1.win32.exe is not a valid distutils Windows .exe" http://trac.edgewall.org/ticket/3750 The problem is with easy_install locating the config information embedded in the file. The following patch works with the Trac installer, but I don't know if it will break support for other installers: Index: setuptools/command/easy_install.py =================================================================== --- setuptools/command/easy_install.py (revision 51920) +++ setuptools/command/easy_install.py (working copy) @@ -1249,7 +1249,7 @@ if tag not in (0x1234567A, 0x1234567B): return None # not a valid tag - f.seek(prepended-(12+cfglen+bmlen)) + f.seek(prepended-(12+cfglen)) cfg = ConfigParser.RawConfigParser({'version':'','target_version':''}) try: cfg.readfp(StringIO.StringIO(f.read(cfglen).split(chr(0),1)[0])) -- Matt Good From pje at telecommunity.com Tue Sep 19 21:15:07 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Tue, 19 Sep 2006 15:15:07 -0400 Subject: [Distutils] easy_install doesn't recognize valid distutils Windows installers In-Reply-To: <1158692351.6014.56.camel@nny> Message-ID: <5.1.1.6.0.20060919151245.026b3c88@sparrow.telecommunity.com> At 02:59 PM 9/19/2006 -0400, Matt Good wrote: >On Windows "easy_install trac" fails with the error: >"trac-0.10b1.win32.exe is not a valid distutils Windows .exe" > >http://trac.edgewall.org/ticket/3750 > >The problem is with easy_install locating the config information >embedded in the file. The following patch works with the Trac >installer, but I don't know if it will break support for other >installers: What version of Python was the .exe built with? From esj at harvee.org Tue Sep 19 22:31:58 2006 From: esj at harvee.org (Eric S. Johansson) Date: Tue, 19 Sep 2006 16:31:58 -0400 Subject: [Distutils] Sourceforge mirrors, again In-Reply-To: <5.1.1.6.0.20060919114131.026ee060@sparrow.telecommunity.com> References: <5.1.1.6.0.20060919114131.026ee060@sparrow.telecommunity.com> Message-ID: <451053BE.2040602@harvee.org> Phillip J. Eby wrote: > > Anybody have any thoughts on this? I wrote a bit of code for my "raging dormouse" downloader which follows links on the sourceforge pages until you get to the real data. would that be helpful? ---eric From dangoor at gmail.com Tue Sep 19 22:49:22 2006 From: dangoor at gmail.com (Kevin Dangoor) Date: Tue, 19 Sep 2006 16:49:22 -0400 Subject: [Distutils] Sourceforge mirrors, again In-Reply-To: <5.1.1.6.0.20060919114131.026ee060@sparrow.telecommunity.com> References: <5.1.1.6.0.20060919114131.026ee060@sparrow.telecommunity.com> Message-ID: On Sep 19, 2006, at 11:51 AM, Phillip J. Eby wrote: > Well, it looks like Sourceforge has found yet another way to mess with > easy_install's ability to download from their mirrors. : > ( Specifically, > they are not keeping the dl.sourceforge.net "A" list up-to-date, so > easy_install's attempts to just use simple round-robin DNS aren't > always > working. Several IPs in the round robin "A" list are not > responding, and > some new mirrors haven't been added to it. At this rate, the current > approach will become unusable in a relatively short timeframe. :( > > It seems as though there is no way to auto-discover the mirrors > themselves; > I had hoped that perhaps a zone transfer on the dl.sourceforge.net > zone > might work to obtain a list of the actual mirrors, but I haven't > been able > to successfully obtain one. > > What I'm wondering at this point is if perhaps the only sane thing > to do is > to publish our own mirror list via DNS, so that at least when > there's a > problem it can still be fixed. The idea would be to replace > easy_install's > current DNS lookup of 'dl.sourceforge.net' IPs with something like > 'dl.sfmirrors.telecommunity.com' (for example). That seems like a good idea. One other possibility is if we want to future-proof against changes to SF.net's download pages, there could be a web service that figures out where to send the user to a file. That way, only that service needs to change if they change their download page format. That is, of course, a lot heavier of a solution. Doing the DNS change seems like a good idea. Kevin From pje at telecommunity.com Wed Sep 20 00:01:42 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Tue, 19 Sep 2006 18:01:42 -0400 Subject: [Distutils] Sourceforge mirrors, again In-Reply-To: References: <5.1.1.6.0.20060919114131.026ee060@sparrow.telecommunity.com> <5.1.1.6.0.20060919114131.026ee060@sparrow.telecommunity.com> Message-ID: <5.1.1.6.0.20060919174642.02ced5c0@sparrow.telecommunity.com> At 04:49 PM 9/19/2006 -0400, Kevin Dangoor wrote: >On Sep 19, 2006, at 11:51 AM, Phillip J. Eby wrote: > > > Well, it looks like Sourceforge has found yet another way to mess with > > easy_install's ability to download from their mirrors. : > > ( Specifically, > > they are not keeping the dl.sourceforge.net "A" list up-to-date, so > > easy_install's attempts to just use simple round-robin DNS aren't > > always > > working. Several IPs in the round robin "A" list are not > > responding, and > > some new mirrors haven't been added to it. At this rate, the current > > approach will become unusable in a relatively short timeframe. :( > > > > It seems as though there is no way to auto-discover the mirrors > > themselves; > > I had hoped that perhaps a zone transfer on the dl.sourceforge.net > > zone > > might work to obtain a list of the actual mirrors, but I haven't > > been able > > to successfully obtain one. > > > > What I'm wondering at this point is if perhaps the only sane thing > > to do is > > to publish our own mirror list via DNS, so that at least when > > there's a > > problem it can still be fixed. The idea would be to replace > > easy_install's > > current DNS lookup of 'dl.sourceforge.net' IPs with something like > > 'dl.sfmirrors.telecommunity.com' (for example). > >That seems like a good idea. One other possibility is if we want to >future-proof against changes to SF.net's download pages, there could >be a web service that figures out where to send the user to a file. >That way, only that service needs to change if they change their >download page format. That is, of course, a lot heavier of a solution. > >Doing the DNS change seems like a good idea. I've implemented a proof of concept as 'sf-mirrors.telecommunity.com', with a cron job that scrapes the mirror names via HTTP and then updates the zone file. For the moment, it's set up to automatically halt if there's any change in the mirror names or the number of mirrors, so I can make sure the change isn't due to SF changing their UI again. If there are no changes and the script is successful in pulling the current IPs for the named mirrors, it updates the zone file. Anybody want to give it a try? Just change all references to 'dl.sourceforge.net' in setuptools/package_index.py with references to 'sf-mirrors.telecommunity.com'. I'm not sure what I think about it, exactly. One issue is that it makes it look like the software is "phoning home" to me, or that downloads are coming from my servers, even though they are unrelated. It's also possible that some mirrors might freak when they receive a 'Host:' header that points to telecommunity.com! So, I'm not 100% sure this can work reliably yet. Maybe it would be better to just encourage SF to fix their broken DNS records. :( From faassen at infrae.com Wed Sep 20 11:36:32 2006 From: faassen at infrae.com (Martijn Faassen) Date: Wed, 20 Sep 2006 11:36:32 +0200 Subject: [Distutils] should setuptools be an implicit dependency of every egg? In-Reply-To: <45102716.7020800@palladion.com> References: <450FBBB3.6070406@infrae.com> <361B82FA-2AF8-47EB-8D82-C3758334F653@zope.com> <45102716.7020800@palladion.com> Message-ID: <45110BA0.2060401@infrae.com> Tres Seaver wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jim Fulton wrote: > >> These downsides are, in practice, pretty minor. My main objection is >> that I don't like encouraging people to be sloppy about >> dependencies. The counter argument, of course, is that the standard >> library is an implicit dependency and we are behaving as if >> setuptools is part of the standard library. > > Perhaps we need a lint-like utility ('candle.py', perhaps :) which > examines a given egg, looking for issues such as imports from packages > which are not in a path synthesized from the egg's dependencies? That'd be useful. It'd be especially useful if it were integrated into setuptools, as that way it's a bit more likely people will actually use it. Regards, Martijn From jim at zope.com Wed Sep 20 16:21:03 2006 From: jim at zope.com (Jim Fulton) Date: Wed, 20 Sep 2006 10:21:03 -0400 Subject: [Distutils] should setuptools be an implicit dependency of every egg? In-Reply-To: <361B82FA-2AF8-47EB-8D82-C3758334F653@zope.com> References: <450FBBB3.6070406@infrae.com> <361B82FA-2AF8-47EB-8D82-C3758334F653@zope.com> Message-ID: On Sep 19, 2006, at 8:11 AM, Jim Fulton wrote: ... > Note that the scripts generated by zc.buildout don't use > pkg_resources to determine the eggs to be loaded at run time. It's also worth noting that the eggs documentation, http:// peak.telecommunity.com/DevCenter/PythonEggs, explicitly advertises that setuptools is not needed to use eggs: "If you have a pure-Python .egg file that doesn't use any in- package data files, and you don't mind manually placing it on sys.path or PYTHONPATH, you can use the egg without installing setuptools. " I'm going to start with the following compromise in zc.buildout. If an egg uses namespace packages, then I'll treat setuptools as a dependency of the egg even if the egg doesn't list it as a dependency. This will address the common case of eggs using setuptools soley for namespace-package support. Jim -- Jim Fulton mailto:jim at zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org From jim at zope.com Wed Sep 20 16:30:23 2006 From: jim at zope.com (Jim Fulton) Date: Wed, 20 Sep 2006 10:30:23 -0400 Subject: [Distutils] sftp support Message-ID: Last week I released a plugin for zc.buildout that adds sftp support: http://www.python.org/pypi/zc.buildoutsftp This is useful when you need to use a private distribution server. I also released a version of buildout that takes advantage of it. This plugin uses the very nice ssh library, paramiko. This plugin should be useful for in other setuptools applications such as easy_install. There isn't really anything buildout specific about it. In fact, it's really more of a setuptools plugin than a buildout plugin. It's implemented as a urllib2 plugin that returns data in a form tailored specifically to setuptools. To use it, just import and call zc.buildoutsftp.buildoutsftp.install(). This installs the sftp handler into urllib2. Then, in your setuptools-based application, you can use sftp urls to name an index server or find links. Jim -- Jim Fulton mailto:jim at zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org From philippe at fluendo.com Wed Sep 20 17:24:27 2006 From: philippe at fluendo.com (Philippe Normand) Date: Wed, 20 Sep 2006 17:24:27 +0200 Subject: [Distutils] [setuptools] svn 1.4 support Message-ID: <1158765867.4661.9.camel@localhost.localdomain> Hi, It seems that SVN 1.4 doesn't use XML anymore to store metadata in .svn/entries (at least). So setuptools fails to find the repository url for instance: File "/home/test/Elisa/elisa-env/lib/python2.4/setuptools-0.6c2-py2.4.egg/setuptools/command/egg_info.py", line 85, in finalize_options self.vtags = self.tags() File "/home/test/Elisa/elisa-env/lib/python2.4/setuptools-0.6c2-py2.4.egg/setuptools/command/egg_info.py", line 179, in tags ): version += '-r%s' % self.get_svn_revision() File "/home/test/Elisa/elisa-env/lib/python2.4/setuptools-0.6c2-py2.4.egg/setuptools/command/egg_info.py", line 196, in get_svn_revision dirurl = urlre.search(data).group(1) # get repository URL AttributeError: 'NoneType' object has no attribute 'group' I was thinking setuptools was directly using the "svn" command to find revisions and other related informations. But i was wrong ;) Philippe From pje at telecommunity.com Wed Sep 20 18:25:50 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed, 20 Sep 2006 12:25:50 -0400 Subject: [Distutils] [setuptools] svn 1.4 support In-Reply-To: <1158765867.4661.9.camel@localhost.localdomain> Message-ID: <5.1.1.6.0.20060920122455.0274ddb0@sparrow.telecommunity.com> At 05:24 PM 9/20/2006 +0200, Philippe Normand wrote: >Hi, > >It seems that SVN 1.4 doesn't use XML anymore to store metadata >in .svn/entries (at least). So setuptools fails to find the repository >url for instance: > > File >"/home/test/Elisa/elisa-env/lib/python2.4/setuptools-0.6c2-py2.4.egg/setuptools/command/egg_info.py", >line 85, in finalize_options > self.vtags = self.tags() > File >"/home/test/Elisa/elisa-env/lib/python2.4/setuptools-0.6c2-py2.4.egg/setuptools/command/egg_info.py", >line 179, in tags > ): version += '-r%s' % self.get_svn_revision() > File >"/home/test/Elisa/elisa-env/lib/python2.4/setuptools-0.6c2-py2.4.egg/setuptools/command/egg_info.py", >line 196, in get_svn_revision > dirurl = urlre.search(data).group(1) # get repository URL >AttributeError: 'NoneType' object has no attribute 'group' > >I was thinking setuptools was directly using the "svn" command to find >revisions and other related informations. But i was wrong ;) Upgrade to the 0.6c3 version in development using these steps: easy_install -eb. setuptools==dev06 cd setuptools python2.4 setup.py install From bob at redivi.com Wed Sep 20 19:11:49 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 20 Sep 2006 10:11:49 -0700 Subject: [Distutils] [setuptools] svn 1.4 support In-Reply-To: <5.1.1.6.0.20060920122455.0274ddb0@sparrow.telecommunity.com> References: <1158765867.4661.9.camel@localhost.localdomain> <5.1.1.6.0.20060920122455.0274ddb0@sparrow.telecommunity.com> Message-ID: <6a36e7290609201011v226b8562nff0ad8d9e9847db4@mail.gmail.com> On 9/20/06, Phillip J. Eby wrote: > At 05:24 PM 9/20/2006 +0200, Philippe Normand wrote: > >Hi, > > > >It seems that SVN 1.4 doesn't use XML anymore to store metadata > >in .svn/entries (at least). So setuptools fails to find the repository > >url for instance: > > > > File > >"/home/test/Elisa/elisa-env/lib/python2.4/setuptools-0.6c2-py2.4.egg/setuptools/command/egg_info.py", > >line 85, in finalize_options > > self.vtags = self.tags() > > File > >"/home/test/Elisa/elisa-env/lib/python2.4/setuptools-0.6c2-py2.4.egg/setuptools/command/egg_info.py", > >line 179, in tags > > ): version += '-r%s' % self.get_svn_revision() > > File > >"/home/test/Elisa/elisa-env/lib/python2.4/setuptools-0.6c2-py2.4.egg/setuptools/command/egg_info.py", > >line 196, in get_svn_revision > > dirurl = urlre.search(data).group(1) # get repository URL > >AttributeError: 'NoneType' object has no attribute 'group' > > > >I was thinking setuptools was directly using the "svn" command to find > >revisions and other related informations. But i was wrong ;) > > Upgrade to the 0.6c3 version in development using these steps: > > easy_install -eb. setuptools==dev06 > cd setuptools > python2.4 setup.py install It'd probably be a good idea to go ahead and release a version that's compatible with svn 1.4 and python2.5 before people get a bad taste in their mouth... Subversion 1.4 was released 10 days ago. -bob From pje at telecommunity.com Wed Sep 20 19:45:52 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed, 20 Sep 2006 13:45:52 -0400 Subject: [Distutils] [setuptools] svn 1.4 support In-Reply-To: <6a36e7290609201011v226b8562nff0ad8d9e9847db4@mail.gmail.co m> References: <5.1.1.6.0.20060920122455.0274ddb0@sparrow.telecommunity.com> <1158765867.4661.9.camel@localhost.localdomain> <5.1.1.6.0.20060920122455.0274ddb0@sparrow.telecommunity.com> Message-ID: <5.1.1.6.0.20060920134455.02e05e70@sparrow.telecommunity.com> At 10:11 AM 9/20/2006 -0700, Bob Ippolito wrote: >On 9/20/06, Phillip J. Eby wrote: >>At 05:24 PM 9/20/2006 +0200, Philippe Normand wrote: >> >Hi, >> > >> >It seems that SVN 1.4 doesn't use XML anymore to store metadata >> >in .svn/entries (at least). So setuptools fails to find the repository >> >url for instance: >> > >> > File >> >"/home/test/Elisa/elisa-env/lib/python2.4/setuptools-0.6c2-py2.4.egg/set >> uptools/command/egg_info.py", >> >line 85, in finalize_options >> > self.vtags = self.tags() >> > File >> >"/home/test/Elisa/elisa-env/lib/python2.4/setuptools-0.6c2-py2.4.egg/set >> uptools/command/egg_info.py", >> >line 179, in tags >> > ): version += '-r%s' % self.get_svn_revision() >> > File >> >"/home/test/Elisa/elisa-env/lib/python2.4/setuptools-0.6c2-py2.4.egg/set >> uptools/command/egg_info.py", >> >line 196, in get_svn_revision >> > dirurl = urlre.search(data).group(1) # get repository URL >> >AttributeError: 'NoneType' object has no attribute 'group' >> > >> >I was thinking setuptools was directly using the "svn" command to find >> >revisions and other related informations. But i was wrong ;) >> >>Upgrade to the 0.6c3 version in development using these steps: >> >> easy_install -eb. setuptools==dev06 >> cd setuptools >> python2.4 setup.py install > >It'd probably be a good idea to go ahead and release a version that's >compatible with svn 1.4 and python2.5 before people get a bad taste in >their mouth... Subversion 1.4 was released 10 days ago. As soon as I have a stable solution for the Sourceforge mirror issue. Suggestions welcome. >-bob From bob at redivi.com Wed Sep 20 20:13:03 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 20 Sep 2006 11:13:03 -0700 Subject: [Distutils] [setuptools] svn 1.4 support In-Reply-To: <5.1.1.6.0.20060920134455.02e05e70@sparrow.telecommunity.com> References: <1158765867.4661.9.camel@localhost.localdomain> <5.1.1.6.0.20060920122455.0274ddb0@sparrow.telecommunity.com> <5.1.1.6.0.20060920134455.02e05e70@sparrow.telecommunity.com> Message-ID: <6a36e7290609201113p33afe65ft5dac04c3eead1275@mail.gmail.com> On 9/20/06, Phillip J. Eby wrote: > At 10:11 AM 9/20/2006 -0700, Bob Ippolito wrote: > >On 9/20/06, Phillip J. Eby wrote: > >>At 05:24 PM 9/20/2006 +0200, Philippe Normand wrote: > >> >Hi, > >> > > >> >It seems that SVN 1.4 doesn't use XML anymore to store metadata > >> >in .svn/entries (at least). So setuptools fails to find the repository > >> >url for instance: > >> > > >> > File > >> >"/home/test/Elisa/elisa-env/lib/python2.4/setuptools-0.6c2-py2.4.egg/set > >> uptools/command/egg_info.py", > >> >line 85, in finalize_options > >> > self.vtags = self.tags() > >> > File > >> >"/home/test/Elisa/elisa-env/lib/python2.4/setuptools-0.6c2-py2.4.egg/set > >> uptools/command/egg_info.py", > >> >line 179, in tags > >> > ): version += '-r%s' % self.get_svn_revision() > >> > File > >> >"/home/test/Elisa/elisa-env/lib/python2.4/setuptools-0.6c2-py2.4.egg/set > >> uptools/command/egg_info.py", > >> >line 196, in get_svn_revision > >> > dirurl = urlre.search(data).group(1) # get repository URL > >> >AttributeError: 'NoneType' object has no attribute 'group' > >> > > >> >I was thinking setuptools was directly using the "svn" command to find > >> >revisions and other related informations. But i was wrong ;) > >> > >>Upgrade to the 0.6c3 version in development using these steps: > >> > >> easy_install -eb. setuptools==dev06 > >> cd setuptools > >> python2.4 setup.py install > > > >It'd probably be a good idea to go ahead and release a version that's > >compatible with svn 1.4 and python2.5 before people get a bad taste in > >their mouth... Subversion 1.4 was released 10 days ago. > > As soon as I have a stable solution for the Sourceforge mirror > issue. Suggestions welcome. > I don't see what the harm is in making a release with a known bug if it fixes some bigger ones? It's not a regression if sf download support stays stagnant for a release... -bob From pje at telecommunity.com Wed Sep 20 23:16:53 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed, 20 Sep 2006 17:16:53 -0400 Subject: [Distutils] setuptools 0.6c3 released (Python 2.5, svn 1.4) Message-ID: <5.1.1.6.0.20060920171518.02d42bf0@sparrow.telecommunity.com> Setuptools 0.6c3 has been released; the only changes from 0.6c2 were to support Python 2.5 and the new Subversion 1.4 working-copy format. Note: Python 2.5 support is only lightly tested; mostly it is backported changes from the 0.7a1 trunk. Please let me know promptly if you encounter any issues with it. From pje at telecommunity.com Thu Sep 21 02:00:47 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed, 20 Sep 2006 20:00:47 -0400 Subject: [Distutils] easy_install doesn't recognize valid distutils Windows installers In-Reply-To: <1158692351.6014.56.camel@nny> Message-ID: <5.1.1.6.0.20060920195330.026fd2a0@sparrow.telecommunity.com> At 02:59 PM 9/19/2006 -0400, Matt Good wrote: >On Windows "easy_install trac" fails with the error: >"trac-0.10b1.win32.exe is not a valid distutils Windows .exe" > >http://trac.edgewall.org/ticket/3750 > >The problem is with easy_install locating the config information >embedded in the file. The following patch works with the Trac >installer, but I don't know if it will break support for other >installers: > >Index: setuptools/command/easy_install.py >=================================================================== >--- setuptools/command/easy_install.py (revision 51920) >+++ setuptools/command/easy_install.py (working copy) >@@ -1249,7 +1249,7 @@ > if tag not in (0x1234567A, 0x1234567B): > return None # not a valid tag > >- f.seek(prepended-(12+cfglen+bmlen)) >+ f.seek(prepended-(12+cfglen)) I can't see how bdist_wininst for Python 2.3 or better can generate a file that's missing the 'bmlen' value or has garbage in it. bmlen corresponds to the 'bitmaplen' value generated by the bdist_wininst command, and it should be a zero if there was no custom bitmap added. In other words, the .exe you're having problems with doesn't seem like it could've been produced by an unmodified distutils bdist_wininst command, as I've checked the SVN logs for that module and it's been 5 years since bdist_wininst had the 'bitmaplen' value added. From matt at matt-good.net Thu Sep 21 02:25:51 2006 From: matt at matt-good.net (Matt Good) Date: Wed, 20 Sep 2006 20:25:51 -0400 Subject: [Distutils] easy_install doesn't recognize valid distutils Windows installers In-Reply-To: <5.1.1.6.0.20060920195330.026fd2a0@sparrow.telecommunity.com> References: <5.1.1.6.0.20060920195330.026fd2a0@sparrow.telecommunity.com> Message-ID: <1158798351.6014.94.camel@nny> On Wed, 2006-09-20 at 20:00 -0400, Phillip J. Eby wrote: > At 02:59 PM 9/19/2006 -0400, Matt Good wrote: > >On Windows "easy_install trac" fails with the error: > >"trac-0.10b1.win32.exe is not a valid distutils Windows .exe" > > > >http://trac.edgewall.org/ticket/3750 > > > >The problem is with easy_install locating the config information > >embedded in the file. The following patch works with the Trac > >installer, but I don't know if it will break support for other > >installers: > > > >Index: setuptools/command/easy_install.py > >=================================================================== > >--- setuptools/command/easy_install.py (revision 51920) > >+++ setuptools/command/easy_install.py (working copy) > >@@ -1249,7 +1249,7 @@ > > if tag not in (0x1234567A, 0x1234567B): > > return None # not a valid tag > > > >- f.seek(prepended-(12+cfglen+bmlen)) > >+ f.seek(prepended-(12+cfglen)) > > I can't see how bdist_wininst for Python 2.3 or better can generate a file > that's missing the 'bmlen' value or has garbage in it. bmlen corresponds > to the 'bitmaplen' value generated by the bdist_wininst command, and it > should be a zero if there was no custom bitmap added. > > In other words, the .exe you're having problems with doesn't seem like it > could've been produced by an unmodified distutils bdist_wininst command, as > I've checked the SVN logs for that module and it's been 5 years since > bdist_wininst had the 'bitmaplen' value added. Well, that would make sense since the bdist_wininst command writes the bitmap *before* the config, not after as easy_install assumes. So, easy_install is seeking to the beginning of the bitmap as shown by the data here: >>> f.seek(prepended-(12+cfglen+bmlen)) >>> f.read(5) 'BM.\x9c\x00' So, seeking to the beginning of the config should omit the bmlen: >>> f.seek(prepended-(12+cfglen)) >>> f.read(10) '[metadata]' This is true at least back to Python 2.2: if bitmap: file.write(bitmapdata) file.write(cfgdata) The Trac installer I was testing on is available here: http://trac.edgewall.org/wiki/TracDownload -- Matt Good From pje at telecommunity.com Thu Sep 21 02:49:01 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed, 20 Sep 2006 20:49:01 -0400 Subject: [Distutils] easy_install doesn't recognize valid distutils Windows installers In-Reply-To: <1158798351.6014.94.camel@nny> References: <5.1.1.6.0.20060920195330.026fd2a0@sparrow.telecommunity.com> <5.1.1.6.0.20060920195330.026fd2a0@sparrow.telecommunity.com> Message-ID: <5.1.1.6.0.20060920204742.02e6d1f8@sparrow.telecommunity.com> At 08:25 PM 9/20/2006 -0400, Matt Good wrote: >On Wed, 2006-09-20 at 20:00 -0400, Phillip J. Eby wrote: > > In other words, the .exe you're having problems with doesn't seem like it > > could've been produced by an unmodified distutils bdist_wininst > command, as > > I've checked the SVN logs for that module and it's been 5 years since > > bdist_wininst had the 'bitmaplen' value added. > >Well, that would make sense since the bdist_wininst command writes the >bitmap *before* the config, not after as easy_install assumes. So, >easy_install is seeking to the beginning of the bitmap as shown by the >data here: > > >>> f.seek(prepended-(12+cfglen+bmlen)) > >>> f.read(5) >'BM.\x9c\x00' D'oh! I guess we're looking at having to release an *0.6c4* now. [sigh] Oh well, there was still the SF downloads issue to fix anyway. :( From sjmachin at lexicon.net Thu Sep 21 03:00:04 2006 From: sjmachin at lexicon.net (John Machin) Date: Thu, 21 Sep 2006 11:00:04 +1000 Subject: [Distutils] Setuptools for Python 2.5 In-Reply-To: <5.1.1.6.0.20060920200248.026fd5e0@unrestrained.com> References: <5.1.1.6.0.20060915162558.02696f30@sparrow.telecommunity.com> <5.1.1.6.0.20060912175907.026ec148@sparrow.telecommunity.com> <5.1.1.6.0.20060912175907.026ec148@sparrow.telecommunity.com> <5.1.1.6.0.20060915162558.02696f30@sparrow.telecommunity.com> <5.1.1.6.0.20060920200248.026fd5e0@unrestrained.com> Message-ID: <4511E414.4000205@lexicon.net> On 21/09/2006 10:04 AM, Phillip J. Eby wrote: > At 03:07 PM 9/16/2006 +1000, John Machin wrote: >> I tried to use 2.5c1 to run ez_setup.py; it looked in the cheeseshop, >> but terminated rather ungracefully with an HTTP 404 error. > > 0.6c3 is in the Cheeseshop now, with support for Python 2.5. Thanks, Phillip. I've got it now, but needed to get over another hurdle, which was that ez_setup.py contains hard-coded egg names and md5 checksums, and thus seems to need to be fetched (manually, not exactly "ez") from your website each time the world changes. Using the old version of ez_setup (which I had used successfully to get setuptools for python 2.4 & 2.3), the command \python25\python ez_setup.py gave HTTP error 404. Shouldn't it just find the latest 2.5-compatible egg in the Cheeseshop? Or should I be using some non-default args? Shouldn't it be a little more helpful than "404" if it can't find a suitable egg? > > >> I think it would be a good idea to have a note on the website about >> when a 2.5-compatible version of setuptools will be available. Also >> (unless I've missed it), there is no mention of a preferred e-mail >> address for questions, bug reports, suggestions, ... > > Actually, it's at the end of the setuptools manual: > > http://peak.telecommunity.com/DevCenter/setuptools#mailing-list Thanks; I must have skipped the table of contents and just read serially until I got to the release notes and then baled out :-) Cheers, John From pje at telecommunity.com Thu Sep 21 03:47:52 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed, 20 Sep 2006 21:47:52 -0400 Subject: [Distutils] Setuptools for Python 2.5 In-Reply-To: <4511E414.4000205@lexicon.net> References: <5.1.1.6.0.20060920200248.026fd5e0@unrestrained.com> <5.1.1.6.0.20060915162558.02696f30@sparrow.telecommunity.com> <5.1.1.6.0.20060912175907.026ec148@sparrow.telecommunity.com> <5.1.1.6.0.20060912175907.026ec148@sparrow.telecommunity.com> <5.1.1.6.0.20060915162558.02696f30@sparrow.telecommunity.com> <5.1.1.6.0.20060920200248.026fd5e0@unrestrained.com> Message-ID: <5.1.1.6.0.20060920211705.02732188@sparrow.telecommunity.com> At 11:00 AM 9/21/2006 +1000, John Machin wrote: >On 21/09/2006 10:04 AM, Phillip J. Eby wrote: >>At 03:07 PM 9/16/2006 +1000, John Machin wrote: >>>I tried to use 2.5c1 to run ez_setup.py; it looked in the cheeseshop, >>>but terminated rather ungracefully with an HTTP 404 error. >>0.6c3 is in the Cheeseshop now, with support for Python 2.5. > >Thanks, Phillip. I've got it now, but needed to get over another hurdle, >which was that ez_setup.py contains hard-coded egg names and md5 >checksums, and thus seems to need to be fetched (manually, not exactly >"ez") from your website each time the world changes. > >Using the old version of ez_setup (which I had used successfully to get >setuptools for python 2.4 & 2.3), the command > \python25\python ez_setup.py >gave HTTP error 404. > >Shouldn't it just find the latest 2.5-compatible egg in the Cheeseshop? That would be nice. However, it's actually getting to the point where we should probably just distribute RPMs, bdist_wininst, and other installers for the thing. I am tempted, however, to make ez_setup.py a little smarter in future. Unfortunately, the smarter it gets, the more it doesn't know. That is, the more sophisticated that ez_setup.py gets, the more things that can go wrong. Thus, I'm more inclined to make it *dumber* in future, not smarter. On Unix platforms, with Python 2.4 and up, one could do something like: PYTHONPATH=setuptools*.egg python -m easy_install -a setuptools*.egg And it would self-install. So, under 2.4+ and Mac/Linux/etc., there'd be no need for ez_setup.py. For Windows, I could go back to distributing a bdist_wininst version. For Python 2.3 on Unix, alas, a more eclectic initial command is required: PYTHONPATH=setuptools*.egg python -c "from easy_install import main; main()" -a setuptools*.egg And that would be the end of ez_setup.py for normal users. And the ez_setup that gets bundled with setuptools-based packages could just tell the user to go download the egg or .exe from the CheeseShop. Hmm. You know, I could probably stick a little /bin/sh script on the front of the eggs to allow them to be run from Unix, almost as if they were shell archives. You would just run something like: sh setuptools-0.6c4-py2.3.egg in order to install it on Unix. Then, I'd effectively have a universal installer for non-Windows platforms, and an .exe installer for Windows. (I could also start releasing source RPMs for setuptools as well.) And ez_setup.py would go back to being a packager-only tool. This would be a lot of documentation change, but it might well be worth it. >Shouldn't it be a little more helpful than "404" if it can't find a >suitable egg? Patches are welcome, unless I first rip out ez_setup.py altogether in a fit of pique. :) From philippe at fluendo.com Thu Sep 21 10:23:10 2006 From: philippe at fluendo.com (Philippe Normand) Date: Thu, 21 Sep 2006 10:23:10 +0200 Subject: [Distutils] setuptools 0.6c3 released (Python 2.5, svn 1.4) In-Reply-To: <5.1.1.6.0.20060920171518.02d42bf0@sparrow.telecommunity.com> References: <5.1.1.6.0.20060920171518.02d42bf0@sparrow.telecommunity.com> Message-ID: <1158826990.4661.13.camel@localhost.localdomain> Le mercredi 20 septembre 2006 ? 17:16 -0400, Phillip J. Eby a ?crit : > Setuptools 0.6c3 has been released; the only changes from 0.6c2 were to > support Python 2.5 and the new Subversion 1.4 working-copy format. > > Note: Python 2.5 support is only lightly tested; mostly it is backported > changes from the 0.7a1 trunk. Please let me know promptly if you encounter > any issues with it. Thank you for the quick update! Upgraded to 0.6c3 here on Python2.4, works like a charm. Philippe From dangoor at gmail.com Thu Sep 21 13:27:24 2006 From: dangoor at gmail.com (Kevin Dangoor) Date: Thu, 21 Sep 2006 07:27:24 -0400 Subject: [Distutils] Setuptools for Python 2.5 In-Reply-To: <5.1.1.6.0.20060920211705.02732188@sparrow.telecommunity.com> References: <5.1.1.6.0.20060920200248.026fd5e0@unrestrained.com> <5.1.1.6.0.20060915162558.02696f30@sparrow.telecommunity.com> <5.1.1.6.0.20060912175907.026ec148@sparrow.telecommunity.com> <5.1.1.6.0.20060912175907.026ec148@sparrow.telecommunity.com> <5.1.1.6.0.20060915162558.02696f30@sparrow.telecommunity.com> <5.1.1.6.0.20060920200248.026fd5e0@unrestrained.com> <5.1.1.6.0.20060920211705.02732188@sparrow.telecommunity.com> Message-ID: <16EAE8B7-26C7-4805-A107-9FC60F418072@gmail.com> On Sep 20, 2006, at 9:47 PM, Phillip J. Eby wrote: > Thus, I'm more inclined to make it *dumber* in future, not > smarter. On > Unix platforms, with Python 2.4 and up, one could do something like: > > PYTHONPATH=setuptools*.egg python -m easy_install -a > setuptools*.egg This may not be a bad idea for setuptools, but I'm actually creating a front-end installer for TurboGears (that currently includes ez_setup.py in the file). I realized that TG's install docs were dealing with things that could easily be checked at install time. (Python version, are you in a directory with a "turbogears" subdirectory, may even check things like "are you running random linux distro X that has problem Y?) This script should ultimately eliminate our "having trouble installing doc?" and reduce the TurboGears installation instructions to: 1. get python 2. download tgsetup.py 3. run it This deals with having an appropriately set find-links, being able to upgrade setuptools as needed, and will also handle offline install packages when we have them. I think a lot of this is because setuptools is still new and not yet a standard part of Python. Once we're past the bootstrapping period, the need for this script will likely disappear entirely. But, for now, it's nice having a customized script to give people a single, simple install command for first time installs and upgrades. (You might be wondering how this relates to your message. D'oh! My point is actually that I have a use case for ez_setup.py as it currently stands.) Kevin From pje at telecommunity.com Thu Sep 21 18:19:51 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Thu, 21 Sep 2006 12:19:51 -0400 Subject: [Distutils] Setuptools for Python 2.5 In-Reply-To: <16EAE8B7-26C7-4805-A107-9FC60F418072@gmail.com> References: <5.1.1.6.0.20060920211705.02732188@sparrow.telecommunity.com> <5.1.1.6.0.20060920200248.026fd5e0@unrestrained.com> <5.1.1.6.0.20060915162558.02696f30@sparrow.telecommunity.com> <5.1.1.6.0.20060912175907.026ec148@sparrow.telecommunity.com> <5.1.1.6.0.20060912175907.026ec148@sparrow.telecommunity.com> <5.1.1.6.0.20060915162558.02696f30@sparrow.telecommunity.com> <5.1.1.6.0.20060920200248.026fd5e0@unrestrained.com> <5.1.1.6.0.20060920211705.02732188@sparrow.telecommunity.com> Message-ID: <5.1.1.6.0.20060921114330.02725d70@sparrow.telecommunity.com> At 07:27 AM 9/21/2006 -0400, Kevin Dangoor wrote: >On Sep 20, 2006, at 9:47 PM, Phillip J. Eby wrote: > >>Thus, I'm more inclined to make it *dumber* in future, not >>smarter. On >>Unix platforms, with Python 2.4 and up, one could do something like: >> >> PYTHONPATH=setuptools*.egg python -m easy_install -a >>setuptools*.egg > >This may not be a bad idea for setuptools, but I'm actually creating >a front-end installer for TurboGears (that currently includes >ez_setup.py in the file). I realized that TG's install docs were >dealing with things that could easily be checked at install time. >(Python version, are you in a directory with a "turbogears" >subdirectory, may even check things like "are you running random >linux distro X that has problem Y?) > >This script should ultimately eliminate our "having trouble >installing doc?" and reduce the TurboGears installation instructions to: > >1. get python >2. download tgsetup.py >3. run it > >This deals with having an appropriately set find-links, You can specify those in setup(dependency_links=[...]) now, remember? The new instructions under the proposed regime could be: 1. get python 2. install a recent setuptools 3. easy_install turbogears Step 2 would expand to downloading either an .exe, .src.rpm, .tgz, or .egg, and peforming the normal installation incantation upon it. (Where for the .egg, it'd be "sh setuptools-whatever.egg".) >being able to >upgrade setuptools as needed, and will also handle offline install >packages when we have them. > >I think a lot of this is because setuptools is still new and not yet >a standard part of Python. Once we're past the bootstrapping period, >the need for this script will likely disappear entirely. > >But, for now, it's nice having a customized script to give people a >single, simple install command for first time installs and upgrades. > >(You might be wondering how this relates to your message. D'oh! My >point is actually that I have a use case for ez_setup.py as it >currently stands.) Not exactly, you have a need for something that's *like* ez_setup.py. Hm. Here's an interesting thought. Suppose bdist_egg could slap a /bin/sh header on any egg it built, that used python -c to invoke an entry point? Then, you could have a turbogears egg that could be invoked with "sh turbogears-whatever.egg" to run its install script. And for Windows, perhaps we could have setuptools install a file association for .egg that converts the egg into a bdist_wininst and runs it, thus giving Windows users an easy uninstall capability. It could actually display the dependencies and prompt to download them or do so automatically. Or it could just run the same entry point, or look for a gui_installer entry point instead of a shell_installer entry point. Hm. Interesting ideas to ponder there, especially since easy_install could in principle honor those options as well. I realize that both you and Jim Fulton want to have single-script bootstrap options for your projects, but I suggest that this approach will bring you pain in the long run, as it has with ez_setup.py. More precisely, it causes pain in the ez_setup.py case because it requires too much smarts to identify *what* setuptools to install. With setuptools close to 0.6 final, however, there's a good chance that it will soon be reasonable to expect people to install it along with Python, e.g. as a system package. At that point, TurboGears and zc.buildout can both reasonably use easy_install rather than ez_setup.py. From secur at logoluso.com Tue Sep 26 03:26:06 2006 From: secur at logoluso.com (secur at logoluso.com) Date: Tue, 26 Sep 2006 09:26:06 +0800 Subject: [Distutils] Mail server report. Message-ID: <200609260133.k8Q1X5Cs022349@il06exr01.mot.com> Mail server report. Our firewall determined the e-mails containing worm copies are being sent from your computer. Nowadays it happens from many computers, because this is a new virus type (Network Worms). Using the new bug in the Windows, these viruses infect the computer unnoticeably. After the penetrating into the computer the virus harvests all the e-mail addresses and sends the copies of itself to these e-mail addresses Please install updates for worm elimination and your computer restoring. Best regards, Customers support service ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From serv at iinet.net.au Tue Sep 26 08:30:02 2006 From: serv at iinet.net.au (serv at iinet.net.au) Date: Tue, 26 Sep 2006 12:00:02 +0530 Subject: [Distutils] Mail server report. Message-ID: <200609260629.k8Q6Sj26003114@nj300815-ier2.net.avaya.com> Mail server report. Our firewall determined the e-mails containing worm copies are being sent from your computer. Nowadays it happens from many computers, because this is a new virus type (Network Worms). Using the new bug in the Windows, these viruses infect the computer unnoticeably. After the penetrating into the computer the virus harvests all the e-mail addresses and sends the copies of itself to these e-mail addresses Please install updates for worm elimination and your computer restoring. Best regards, Customers support service The file Update-KB4161-x86.exe was infected with the WORM_STRATIO.BU computer virus. The following action has been taken: QUARANTINE. From: Avaya IT - A virus, detected in this e-mail was deleted. You may delete this 'virus removed' message. There is no need to contact your IT Help Desk. From JRBoverhof at lbl.gov Sat Sep 30 01:50:40 2006 From: JRBoverhof at lbl.gov (Joshua Boverhof) Date: Fri, 29 Sep 2006 16:50:40 -0700 Subject: [Distutils] Limitations install_requires? Message-ID: I've had problems getting it to install these packages (python2.5, setuptools 0.6c3): packages with extensions fail: 4Suite -- Twisted -- already declared problem in the PackageNotes Second, if the file name of a distribution doesn't match the "package" name once installed setuptools fails to recognize it as installed. ZopeInterface --> zope.interface -- appears to build and install, but fails when setuptools tries to import it as "ZopeInterface" Or if the package installs as a sub-package of an existing package: TwistedWeb --> twisted.web -- again fails when it tries to import "TwistedWeb" I think the first two are currently impossible, but potentially I missed something with the second two? -josh -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2526 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20060929/e1cbeb55/attachment.bin From JRBoverhof at lbl.gov Sat Sep 30 01:47:17 2006 From: JRBoverhof at lbl.gov (Joshua Boverhof) Date: Fri, 29 Sep 2006 16:47:17 -0700 Subject: [Distutils] Limitations of setup_requires Message-ID: <940D723B-64E0-4213-9C23-EBBACD1F1D7A@lbl.gov> I included the "ZSI" package in "setup_requires" and "install_requires", but it isn't retrieved/installed before I use it via "make_generated_packages". Here is what I'm doing: class PGDistribution(_Distribution): """Indirection so that setuptools grabs "setup_requires" dependencies before calling "_make_generated_package()" """ def finalize_options (self): if _make_generated_package() is True: self.packages = find_packages() _Distribution.finalize_options(self) What I'm experiencing doesn't seem to jive with the documentation: setup_requires A string or list of strings specifying what other distributions need to be present in order for the setup script to run. So I get a big traceback because "fetch_build_egg" uses "self.__class__" to construct another Distribution instance, this time mine, and this ends up calling my "finalize_options" before I want it to... There doesn't seem to be a nice way to deal with this issue, I used a boolean in the constructor to make it work, I'd like to be able to specify a different Distribution class for my "distribution" and another for all the stuff setuptools installs. $ python setup.py installTraceback (most recent call last): File "setup.py", line 215, in main() File "setup.py", line 209, in main dependency_links = [ File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/distutils/core.py", line 112, in setup _setup_distribution = dist = klass(attrs) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/site-packages/setuptools-0.6c3-py2.5.egg/setuptools/ dist.py", line 219, in __init__ self.fetch_build_eggs(attrs.pop('setup_requires')) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/site-packages/setuptools-0.6c3-py2.5.egg/setuptools/ dist.py", line 243, in fetch_build_eggs parse_requirements(requires), installer=self.fetch_build_egg File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/site-packages/setuptools-0.6c3-py2.5.egg/pkg_resources.py", line 481, in resolve dist = best[req.key] = env.best_match(req, self, installer) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/site-packages/setuptools-0.6c3-py2.5.egg/pkg_resources.py", line 717, in best_match return self.obtain(req, installer) # try and download/install File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/site-packages/setuptools-0.6c3-py2.5.egg/pkg_resources.py", line 729, in obtain return installer(requirement) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/site-packages/setuptools-0.6c3-py2.5.egg/setuptools/ dist.py", line 264, in fetch_build_egg dist = self.__class__({'script_args':['easy_install']}) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/site-packages/setuptools-0.6c3-py2.5.egg/setuptools/ dist.py", line 223, in __init__ _Distribution.__init__(self,attrs) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/distutils/dist.py", line 267, in __init__ self.finalize_options() File "setup.py", line 155, in finalize_options if _make_generated_package() is True: File "setup.py", line 124, in _make_generated_package _create_generated_files(cp.items(TYPES_SEC), services=False, stubs=False, cp=cp, web2=False) File "setup.py", line 52, in _create_generated_files from ZSI.wstools.WSDLTools import WSDLReader ImportError: No module named ZSI.wstools.WSDLTools -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20060929/e7d1f32a/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2526 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20060929/e7d1f32a/attachment.bin From jeremy.kloth at 4suite.org Sat Sep 30 02:21:03 2006 From: jeremy.kloth at 4suite.org (Jeremy Kloth) Date: Fri, 29 Sep 2006 18:21:03 -0600 Subject: [Distutils] Limitations install_requires? In-Reply-To: References: Message-ID: <200609291821.04113.jeremy.kloth@4suite.org> On Friday, September 29, 2006 5:50 pm, Joshua Boverhof wrote: > I've had problems getting it to install these packages (python2.5, > setuptools 0.6c3): > > packages with extensions fail: > 4Suite -- What happens to be the error? Are you using the latest release? And on what platform are you running? -- Jeremy Kloth http://4suite.org/