Mailman 3 September 2007 - Distutils-SIG

install_recommends proposal
by Martijn Faassen 09 Oct '07

09 Oct '07

Hi there, Currently setup.py allows install_requires to specify the dependencies, possibly including exact version numbers of a package. It is however beneficial to only specify the *minimum* of expected requirements in there, to retain maximum flexibility of use. This means you'd typically say: install_requires = [ 'foo', 'bar >= 1.3', ] if you know you need some version of foo, and at least version 1.3 of your package. This allows developers who use your package to choose themselves which version of foo and bar they want to use, without getting version conflicts as long as you stay within the stated constraints. If you write a framework, or a library that uses other libraries, you sometimes want to do something more. You'd like to ensure that if someone uses version X of your framework, they use a list of *exact* dependencies, that is, exactly foo 1.2 and bar 1.4.3. This makes all installations of framework X bug for bug compatible. New releases of packages you depend on don't break your framework install, as the framework install will ensure those versions. I'd therefore like to propose a new setup.py section where these can be specified: install_recommends = [ 'foo == 1.2', 'bar == 1.4.3', ] The person or tool installing the package is entirely free to ignore this information; it's a recommendation, not a requirement. The only specifications that can be made are *exact*; there is no support for anything but '=='. Distutils at most needs to be taught that install_recommends cannot directly conflict with install_requires. This would be a conflict: install_requires = [ 'bar > 1.3' ], install_recommends = [ 'bar == 1.2', ] By default, distutils and setuptools would otherwise ignore this information. I do presume setuptools would include this information in egg-info so that external tools can make use of it. This information can then be (optionally) used by a tool like buildout to ensure exact dependencies are installed (once zc.buildout is taught to use this information, of course). This means I can release a framework that allows flexibility to knowledgable developers, but also, in its default install, doesn't have the chance of breaking the moment someone releases a new version of some dependency. For an extensive article where I describe what led me to look for this read this: http://faassen.n--tree.net/blog/view/weblog/2007/09/26/0 It goes into much detail on the concerns and reasoning behind this in the context of the development of Zope 3, and Grok, a framework based on many Zope 3 packages. This isn't a theoretical problem but is currently biting us regularly. I'll also note that it looks like zc.buildout doesn't appear to need much work to start using this information (but Jim will correct me if I'm wrong). Regards, Martijn

7 10

patches: ez_setup.py: don't import setuptools into your current address space in order to learn its version number
by zooko 06 Oct '07

06 Oct '07

Folks: We're gradually converting the allmydata.org tahoe project [1] and its spin-off packages to use setuptools. One problem that comes up is that ez_setup.py might require a newer version of setuptools than the version of setuptools already installed. For example, although Tahoe currently uses setuptools to manage its dependencies on zfec, foolscap, and nevow [2], but if we execute simplejson's ez_setup.py then it requires setuptools v0.6c7 and refuses to proceed if an earlier version is installed. One solution for this problem could be for the packager of simplejson (Bob Ippolito) to use the "min_version" patch that we contributed to ez_setup.py [3]. This is assuming that simplejson doesn't actually *require* the latest version of setuptools, and we could successfully install with a slightly older version, but what if a package actually does require a newer version of setuptools than the one that is already installed? The following patch was created by Tahoe contributor Arno Washck and then modified by me in order to get around such a problem. The idea is simple enough -- reload setuptools. There may be some subtleties that we still need to work out. This patch hasn't been tested in its current form. --- ez_setup.py~ 2007-09-10 12:36:30.000000000 -0600 +++ ez_setup.py 2007-09-18 15:15:23.000000000 -0600 @@ -95,13 +95,9 @@ pkg_resources.require("setuptools>="+version) except pkg_resources.VersionConflict, e: - # XXX could we install in a subprocess here? - print >>sys.stderr, ( - "The required version of setuptools (>=%s) is not available, and\n" - "can't be installed while this script is running. Please install\n" - " a more recent version first.\n\n(Currently using %r)" - ) % (version, e.args[0]) - sys.exit(2) + egg = download_setuptools(version, download_base, to_dir, download_delay) + sys.path.insert(0, egg) + reload(setuptools); setuptools.bootstrap_install_from = egg def download_setuptools( version=DEFAULT_VERSION, download_base=DEFAULT_URL, to_dir=os.curdir, ------- An alternative idea figure out the version of the current install of setuptools without importing the package. The following patch might accomplish that. It is also not tested. --- ez_setup.py~ 2007-09-10 12:36:30.000000000 -0600 +++ ez_setup.py 2007-09-18 15:26:50.000000000 -0600 @@ -77,31 +77,13 @@ this routine will print a message to ``sys.stderr`` and raise SystemExit in an attempt to abort the calling script. """ - try: - import setuptools - if setuptools.__version__ == '0.0.1': - print >>sys.stderr, ( - "You have an obsolete version of setuptools installed. Please\n" - "remove it from your system entirely before rerunning this script." - ) - sys.exit(2) - except ImportError: - egg = download_setuptools(version, download_base, to_dir, download_delay) - sys.path.insert(0, egg) - import setuptools; setuptools.bootstrap_install_from = egg - + verstr = os.system("python -c \"import setuptools;print setuptools.__version__\"") import pkg_resources - try: - pkg_resources.require("setuptools>="+version) - except pkg_resources.VersionConflict, e: - # XXX could we install in a subprocess here? - print >>sys.stderr, ( - "The required version of setuptools (>=%s) is not available, and\n" - "can't be installed while this script is running. Please install\n" - " a more recent version first.\n\n(Currently using %r)" - ) % (version, e.args[0]) - sys.exit(2) + if pkg_resources.parse_version(verstr) < pkg_resources.parse_version(version): + egg = download_setuptools(version, download_base, to_dir) + sys.path.insert(0, egg) + import setuptools; setuptools.bootstrap_install_from = egg def download_setuptools( version=DEFAULT_VERSION, download_base=DEFAULT_URL, to_dir=os.curdir, ------- Regards, Zooko [1] http://allmydata.org [2] http://allmydata.org/trac/tahoe/browser/calcdeps.py [3] http://mail.python.org/pipermail/distutils-sig/2007-September/ 008257.html

2 12

errors compiling c++ extensions with swig on windows
by Karl Kobata 01 Oct '07

01 Oct '07

Christian, Did you get a reply for your questions? If so, please forward or post. Thanks karl

2 1

zc.recipe.egg extension supporting "easy_install --editable" and running arbitrary setup.py commands
by Ross Patterson 01 Oct '07

01 Oct '07

I wrote some recipes that extend the base zc.recipe.egg recipes. They currently live in my own namespace for development. The recipe code has good test coverage and documentation. I'm wondering if there's any interesting in incorporating them into zc.recipe.egg. If so, I'll be happy to integrate it and commit or submit patches. If not, I'll just release it as z3c.recipe.egg. The editable recipe adds support for downloading source distributions using easy_install. A svn checkout can be done if the appropriate find-link is available. Also, it also allows build-directory to be specified and as such if build-directory is not in the part directory, the source distribution will be preserved when buildout is run. So among other things, this allow for preserving source distributions in development. Unfortunately, this duplicates the effort in ???. I should have released sooner. The setup recipe simply calls arbitrary setup.py commands in specified source distributions. I use this, for example, in buildout files that release multiple projects at once. Below I've attached the documentation for the two recipes for further view. You can see or checkout the source here: https://svn.plone.org/svn/collective/grouparchy/grouparchy.recipe.egg/trunk/ Ross ;-*-Doctest-*- ====================== Editable Distributions ====================== The grouparchy.recipe.egg.Editable recipe use the easy_install --editable and --build-directory options to download a source distribution. If no build-directory is specified the part directory will be used. >>> write(sample_buildout, 'buildout.cfg', ... """ ... [buildout] ... parts = demoneeded ... ... [demoneeded] ... recipe = grouparchy.recipe.egg:editable ... find-links = %(server)s ... """ % dict(server=link_server)) >>> print system(buildout), Installing demoneeded. >>> ls(sample_buildout, 'parts', 'demoneeded') d demoneeded If the develop option is true then the distributions will be installed in develop mode. >>> write(sample_buildout, 'buildout.cfg', ... """ ... [buildout] ... parts = demoneeded ... ... [demoneeded] ... recipe = grouparchy.recipe.egg:editable ... find-links = %(server)s ... eggs = demoneeded ... develop = true ... """ % dict(server=link_server)) >>> print system(buildout), Uninstalling demoneeded. Installing demoneeded. Develop: '/sample-buildout/parts/demoneeded/demoneeded' >>> ls(sample_buildout, 'develop-eggs') - demoneeded.egg-link - grouparchy.recipe.egg.egg-link - zc.recipe.egg.egg-link Multiple distributions can be specified. >>> write(sample_buildout, 'buildout.cfg', ... """ ... [buildout] ... parts = demoneeded ... ... [demoneeded] ... recipe = grouparchy.recipe.egg:editable ... find-links = %(server)s ... eggs = demoneeded ... extdemo ... """ % dict(server=link_server)) >>> print system(buildout), Uninstalling demoneeded. Installing demoneeded. >>> ls(sample_buildout, 'parts', 'demoneeded') d demoneeded d extdemo If a new qualifying version is available then the part will be reinstalled. >>> write( ... sample_buildout, 'parts', 'demoneeded', 'demoneeded', ... 'setup.py', """ ... from setuptools import setup ... setup(name='demoneeded', py_modules=['eggrecipedemobeeded'], ... zip_safe=True, version='1.3', author='bob', ... url='bob', author_email='bob') ... """) >>> import os >>> sdist(os.path.join( ... sample_buildout, 'parts', 'demoneeded', 'demoneeded'), ... sample_eggs) >>> print system(buildout), Uninstalling demoneeded. Installing demoneeded. >>> ls(sample_buildout, 'parts', 'demoneeded') d demoneeded d extdemo >>> cat( ... sample_buildout, 'parts', 'demoneeded', 'demoneeded', ... 'setup.py') <BLANKLINE> from setuptools import setup setup(name='demoneeded', py_modules=['eggrecipedemobeeded'], zip_safe=True, version='1.3', author='bob', url='bob', author_email='bob') If the part is not to be reinstalled, running buildout in offline or non-newest mode, the recipe preserves the existing installation. >>> print system(buildout+' -No'), Updating demoneeded. >>> ls(sample_buildout, 'parts', 'demoneeded') d demoneeded d extdemo If the part is to be reinstalled and buildout is run in offline or non-newest mode, the recipe does nothing. >>> write(sample_buildout, 'buildout.cfg', ... """ ... [buildout] ... parts = demoneeded ... ... [demoneeded] ... recipe = grouparchy.recipe.egg:editable ... find-links = %(server)s ... eggs = demoneeded ... """ % dict(server=link_server)) >>> print system(buildout+' -N'), Uninstalling demoneeded. Installing demoneeded. >>> ls(sample_buildout, 'parts') >>> write(sample_buildout, 'buildout.cfg', ... """ ... [buildout] ... parts = demoneeded ... ... [demoneeded] ... recipe = grouparchy.recipe.egg:editable ... find-links = %(server)s ... eggs = demoneeded ... extdemo ... """ % dict(server=link_server)) >>> print system(buildout+' -o'), Uninstalling demoneeded. Installing demoneeded. >>> ls(sample_buildout, 'parts') If build-directory is specified, the source distributions will be extracted there. >>> mkdir(sample_buildout, 'src') >>> write(sample_buildout, 'buildout.cfg', ... """ ... [buildout] ... parts = demoneeded ... ... [demoneeded] ... recipe = grouparchy.recipe.egg:editable ... find-links = %(server)s ... eggs = demoneeded ... extdemo ... build-directory = src ... """ % dict(server=link_server)) >>> print system(buildout), Uninstalling demoneeded. Installing demoneeded. >>> ls(sample_buildout, 'parts') >>> ls(sample_buildout, 'src') d demoneeded d extdemo If the build directory is present, it will not be removed when the part is installed preserving any changes. >>> write( ... sample_buildout, 'src', 'demoneeded', 'setup.py', """ ... from setuptools import setup ... setup(name='demoneeded', py_modules=['eggrecipedemobeeded'], ... zip_safe=True, version='1.4', author='bob', ... url='bob', author_email='bob') ... """) >>> write(sample_buildout, 'buildout.cfg', ... """ ... [buildout] ... parts = demo ... ... [demo] ... recipe = grouparchy.recipe.egg:editable ... find-links = %(server)s ... eggs = demoneeded ... extdemo ... build-directory = src ... """ % dict(server=link_server)) >>> print system(buildout), Uninstalling demoneeded. Installing demo. >>> ls(sample_buildout, 'src') d demoneeded d extdemo >>> cat( ... sample_buildout, 'src', 'demoneeded', 'setup.py') <BLANKLINE> from setuptools import setup setup(name='demoneeded', py_modules=['eggrecipedemobeeded'], zip_safe=True, version='1.4', author='bob', url='bob', author_email='bob') ;-*-Doctest-*- ===================== Running Setup Scripts ===================== The grouparchy.recipe.egg.Setup recipe calls arbitrary setup.py commands on a distribution in a buildout. The buildout requires only the setup argument which specifies a setup script or the directory containing a setup.py script. >>> write(sample_buildout, 'buildout.cfg', ... """ ... [buildout] ... parts = foo ... ... [foo] ... recipe = grouparchy.recipe.egg:setup ... setup = foo ... args = sdist ... """) The seupt script is run with the specified arguments. >>> print system(buildout), Installing foo. Running setup script '/sample-buildout/foo/setup.py'. running sdist running egg_info creating foo.egg-info writing foo.egg-info/PKG-INFO writing top-level names to foo.egg-info/top_level.txt writing dependency_links to foo.egg-info/dependency_links.txt writing manifest file 'foo.egg-info/SOURCES.txt' writing manifest file 'foo.egg-info/SOURCES.txt' creating foo-0.0.0 creating foo-0.0.0/foo creating foo-0.0.0/foo.egg-info making hard links in foo-0.0.0... hard linking README.txt -> foo-0.0.0 hard linking setup.py -> foo-0.0.0 hard linking foo/__init__.py -> foo-0.0.0/foo hard linking foo.egg-info/PKG-INFO -> foo-0.0.0/foo.egg-info hard linking foo.egg-info/SOURCES.txt -> foo-0.0.0/foo.egg-info hard linking foo.egg-info/dependency_links.txt -> foo-0.0.0/foo.egg-info hard linking foo.egg-info/top_level.txt -> foo-0.0.0/foo.egg-info Writing foo-0.0.0/setup.cfg creating dist tar -cf dist/foo-0.0.0.tar foo-0.0.0 gzip -f9 dist/foo-0.0.0.tar removing 'foo-0.0.0' (and everything under it) >>> ls(sample_buildout, 'foo', 'dist') - foo-0.0.0.tar.gz >>> remove(sample_buildout, 'foo', 'dist', 'foo-0.0.0.tar.gz') The setup script is also run on update. >>> print system(buildout), Updating foo. Running setup script '/sample-buildout/foo/setup.py'. running sdist running egg_info writing foo.egg-info/PKG-INFO writing top-level names to foo.egg-info/top_level.txt writing dependency_links to foo.egg-info/dependency_links.txt writing manifest file 'foo.egg-info/SOURCES.txt' creating foo-0.0.0 creating foo-0.0.0/foo creating foo-0.0.0/foo.egg-info making hard links in foo-0.0.0... hard linking README.txt -> foo-0.0.0 hard linking setup.py -> foo-0.0.0 hard linking foo/__init__.py -> foo-0.0.0/foo hard linking foo.egg-info/PKG-INFO -> foo-0.0.0/foo.egg-info hard linking foo.egg-info/SOURCES.txt -> foo-0.0.0/foo.egg-info hard linking foo.egg-info/dependency_links.txt -> foo-0.0.0/foo.egg-info hard linking foo.egg-info/top_level.txt -> foo-0.0.0/foo.egg-info Writing foo-0.0.0/setup.cfg tar -cf dist/foo-0.0.0.tar foo-0.0.0 gzip -f9 dist/foo-0.0.0.tar removing 'foo-0.0.0' (and everything under it) >>> ls(sample_buildout, 'foo', 'dist') - foo-0.0.0.tar.gz >>> remove(sample_buildout, 'foo', 'dist', 'foo-0.0.0.tar.gz') Multiple setup directories or scripts can be specified. Add the second distribution. >>> write(sample_buildout, 'buildout.cfg', ... """ ... [buildout] ... parts = foo ... ... [foo] ... recipe = grouparchy.recipe.egg:setup ... setup = ... foo ... bar ... args = sdist ... """) Now the buildout will run the setup script on both. >>> print system(buildout), Uninstalling foo. Installing foo. Running setup script '/sample-buildout/foo/setup.py'. running sdist running egg_info writing foo.egg-info/PKG-INFO writing top-level names to foo.egg-info/top_level.txt writing dependency_links to foo.egg-info/dependency_links.txt writing manifest file 'foo.egg-info/SOURCES.txt' creating foo-0.0.0 creating foo-0.0.0/foo creating foo-0.0.0/foo.egg-info making hard links in foo-0.0.0... hard linking README.txt -> foo-0.0.0 hard linking setup.py -> foo-0.0.0 hard linking foo/__init__.py -> foo-0.0.0/foo hard linking foo.egg-info/PKG-INFO -> foo-0.0.0/foo.egg-info hard linking foo.egg-info/SOURCES.txt -> foo-0.0.0/foo.egg-info hard linking foo.egg-info/dependency_links.txt -> foo-0.0.0/foo.egg-info hard linking foo.egg-info/top_level.txt -> foo-0.0.0/foo.egg-info Writing foo-0.0.0/setup.cfg tar -cf dist/foo-0.0.0.tar foo-0.0.0 gzip -f9 dist/foo-0.0.0.tar removing 'foo-0.0.0' (and everything under it) Running setup script '/sample-buildout/bar/setup.py'. running sdist running egg_info creating bar.egg-info writing bar.egg-info/PKG-INFO writing top-level names to bar.egg-info/top_level.txt writing dependency_links to bar.egg-info/dependency_links.txt writing manifest file 'bar.egg-info/SOURCES.txt' writing manifest file 'bar.egg-info/SOURCES.txt' creating bar-0.0.0 creating bar-0.0.0/bar creating bar-0.0.0/bar.egg-info making hard links in bar-0.0.0... hard linking README.txt -> bar-0.0.0 hard linking setup.py -> bar-0.0.0 hard linking bar/__init__.py -> bar-0.0.0/bar hard linking bar.egg-info/PKG-INFO -> bar-0.0.0/bar.egg-info hard linking bar.egg-info/SOURCES.txt -> bar-0.0.0/bar.egg-info hard linking bar.egg-info/dependency_links.txt -> bar-0.0.0/bar.egg-info hard linking bar.egg-info/top_level.txt -> bar-0.0.0/bar.egg-info Writing bar-0.0.0/setup.cfg creating dist tar -cf dist/bar-0.0.0.tar bar-0.0.0 gzip -f9 dist/bar-0.0.0.tar removing 'bar-0.0.0' (and everything under it) >>> ls(sample_buildout, 'foo', 'dist') - foo-0.0.0.tar.gz >>> ls(sample_buildout, 'bar', 'dist') - bar-0.0.0.tar.gz >>> remove(sample_buildout, 'foo', 'dist', 'foo-0.0.0.tar.gz') >>> remove(sample_buildout, 'bar', 'dist', 'bar-0.0.0.tar.gz') If the develop option is true then the distributions will be installed in develop mode. >>> write(sample_buildout, 'buildout.cfg', ... """ ... [buildout] ... parts = foo ... ... [foo] ... recipe = grouparchy.recipe.egg:setup ... setup = foo ... bar ... develop = true ... """) >>> print system(buildout), Uninstalling foo. Installing foo. Develop: '/sample-buildout/foo' Develop: '/sample-buildout/bar' >>> ls(sample_buildout, 'develop-eggs') - bar.egg-link - foo.egg-link - grouparchy.recipe.egg.egg-link - zc.recipe.egg.egg-link

1 0

patch: ez_setup.py: separate default version and minimum version of setuptools
by zooko 29 Sep '07

29 Sep '07

Folks: Thank you for setuptools! We are using it in the Allmydata-Tahoe project [1]. We've patched ez_setup.py so that installation can proceed if an older version of setuptools is already present, as long as that version is not too old. This allows ez_setup.py to work seamlessly in more situations. Please apply. The patch is in-lined and attached. Regards, Zooko [1] http://allmydata.org Thu Sep 13 20:20:02 PDT 2007 zooko(a)zooko.com * change the 'ez_setup.py' script to have distinct desired & minimum required versions of setuptools Note that this preserves backwards compatibility -- if no minimum version is specified then the default version is used as the minimum version, which is identical to the behavior before this patch. This patch is originally due to Rob Kinninmont. diff -rN -u old-setuptools/setuptools-0.6c7/ez_setup.py new- setuptools/setuptools-0.6c7/ez_setup.py --- old-setuptools/setuptools-0.6c7/ez_setup.py 2007-09-13 20:20:58.000000000 -0700 +++ new-setuptools/setuptools-0.6c7/ez_setup.py 2007-09-13 20:20:58.000000000 -0700 @@ -61,7 +61,7 @@ def use_setuptools( version=DEFAULT_VERSION, download_base=DEFAULT_URL, to_dir=os.curdir, - download_delay=15 + download_delay=15, min_version=None ): """Automatically find/download setuptools and make it available on sys.path @@ -89,7 +89,9 @@ import pkg_resources try: - pkg_resources.require("setuptools>="+version) + if not min_version: + min_version = version + pkg_resources.require("setuptools>="+min_version) except pkg_resources.VersionConflict, e: # XXX could we install in a subprocess here? @@ -97,7 +99,7 @@ "The required version of setuptools (>=%s) is not available, and\n" "can't be installed while this script is running. Please install\n" " a more recent version first.\n\n(Currently using %r)" - ) % (version, e.args[0]) + ) % (min_version, e.args[0]) sys.exit(2) def download_setuptools(

2 8

Re: [Distutils] Git plugin for setuptools
by Phillip J. Eby 28 Sep '07

28 Sep '07

At 02:30 PM 9/27/2007 -0400, Yannick Gingras wrote: >"Phillip J. Eby" <pje(a)telecommunity.com> writes: > > > Distribution would be best; I don't want setuptools invoking > > executables on the off-chance that they're installed. It would add > > overhead to every operation. To be considered for inclusion in > > setuptools proper, I would need it to perform all its operations > > without needing an external program, and a reference to the file > > format it's using so I don't end up having to support it with no idea > > how it works. > > > > For separately distributed file-finder plugins, it's okay for them to > > depend on external programs, since presumably a user who installs the > > plugin has the needed programs. > >Fair enough. The git file format is a bit ugly and using git to parse >it is probably the most sensible thing to do. External distribution >is a perfectly reasonable solution. > >Is there a naming convention for SCM plugins? Could Setuptools add a >list of available plugins on it's website? I know there is a pluging >for Mercurial: > > http://cheeseshop.python.org/pypi/hg.setuptools/ > >But without a naming conventions, I would not be likely to find a >plugin for a particular SCM even it exists. Well, you can search for your SCM on PyPI, which works for Mercurial and bzr, at least.

1 0

licenses for ez_setup and virtual_python
by Chris McDonough 27 Sep '07

27 Sep '07

We'd like to distribute ez_setup.py and virtual_python.py with a good number of our packages. I suspect ez_setup.py is licensed under the same dual ZPL/PSF license as is setuptools. I'm not sure how virtual_python.py is licensed (I got it from From http:// peak.telecommunity.com/dist/virtual-python.py). I'd like to do the right thing for licensing and attribution. What would the authors of these packages like to see as far as attribution and licensing artifacts in packages that include them? - C

2 1

Re: [Distutils] Git plugin for setuptools
by Phillip J. Eby 27 Sep '07

27 Sep '07

(Please direct emails like this to the distutils-sig in future.) At 12:54 PM 9/27/2007 -0400, Yannick Gingras wrote: >Hi, > I coded a Git plugin for Setuptools. I posted to the distutils >mailing list but my message doesn't seem to show up. A spam filter >must have eaten it. > >The plugin is here: > > http://ygingras.net/files/gitlsfiles-0.1.1.tar.gz > http://ygingras.net/files/gitlsfiles-0.1.1-py2.4.egg > http://ygingras.net/files/gitlsfiles-0.1.1-py2.5.egg > >I tested it, so did a random beta tester on #python. Could you review >it? It's really simple. If it looks good, should I distribute it >as-is or would it be best to merge it in the Setuptools distrubution? Distribution would be best; I don't want setuptools invoking executables on the off-chance that they're installed. It would add overhead to every operation. To be considered for inclusion in setuptools proper, I would need it to perform all its operations without needing an external program, and a reference to the file format it's using so I don't end up having to support it with no idea how it works. For separately distributed file-finder plugins, it's okay for them to depend on external programs, since presumably a user who installs the plugin has the needed programs.

1 0

Re: [Distutils] easy_install should consider the development status of packages
by Phillip J. Eby 27 Sep '07

27 Sep '07

At 07:18 AM 9/15/2007 -0400, Alexander Michael wrote: >A related desire of mine is to have both the latest stable release of >an egg and the latest development release installed with *the latest >stable release being the default* (i.e. listed, with all its stable >dependencies, in easy-install.pth). Something along the lines of an -M >option, which like -m, performs a multi-version install but doesn't >touch easy-install.pth. I'm not sure if this is feasible (or maybe it >is even already possible!), but it sounds nice to me. :) Have you tried: easy_install pkg==unstable pkg==stable

1 0

easy_install should consider the development status of packages
by Stefan Behnel 27 Sep '07

27 Sep '07

Hi, currently, lxml has both a stable release series (1.3.x) and an unstable alpha release series (2.0alphaX) on PyPI. When you "easy_install lxml", you get the 2.0alpha version. I don't think that's what users expect and it's definitely not what most users want, but at the same time I would like to keep 2.0 visible and easy_install-able to make people aware of it and to let them decide by themselves. I would like to have easy_install changed to either consider the Trove development status of a package and prefer the highest one (or at least those from 5 up), and/or to check the version string for the typical alpha/beta substrings and ignore them by default. It would then be easy to add a command line option like "--unstable" for those who know better. Any comments on that? Stefan

3 2