Mailman 3 September 2006 - Distutils-SIG

Re: [Distutils] Improving setuptools bootstrapping
by Phillip J. Eby 06 Sep '06

06 Sep '06

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.

1 0

Improving setuptools bootstrapping
by Phillip J. Eby 05 Sep '06

05 Sep '06

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?

3 2

Re: [Distutils] problem finding an entry point
by Phillip J. Eby 05 Sep '06

05 Sep '06

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.

2 1

problem finding an entry point
by Kevin Dangoor 01 Sep '06

01 Sep '06

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(a)blazingthings.com company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com

1 0