Distutils-SIG October 2007

distutils-sig@python.org

30 participants
59 discussions

setup.py develop and egg_info conflicting

by Dobes Vandermeer

If I do a setup.py develop, it installs a bunch of scripts I'm using. Then, for deployment, I use setup.py egg_info --tag-svn-revision. Unfortunately, now the scripts won't work; they report pkg_resources.DistributionNotFound: ... So I have to run setup.py develop again before I can use the scripts. Is there a workaround for this?

12 years, 11 months

Re: [Distutils] windows installer and setuptools

by Phillip J. Eby

At 02:30 PM 10/16/2007 +0200, henk-jan ebbers wrote: >But aren't python windows installers supposed to be python-version >independent? Not if they contain extensions, or are built by setuptools. >(but then, I do not understand why a (pure) python egg is version dependent). 1. Because it contains compiled bytecode, which is Python version dependent. 2. Because it may contain different contents or dependencies, based on the Python version. #2 is also why setuptools builds version-dependent bdist_wininst installers. (By the way, please stop emailing me off-list; I don't support setuptools except via the distutils-sig mailing list.)

12 years, 11 months

Re: [Distutils] windows installer and setuptools

by Phillip J. Eby

At 06:27 AM 10/16/2007 +0200, henk-jan ebbers wrote: >Phillip J. Eby wrote: >>At 12:22 AM 10/16/2007 +0200, henk-jan ebbers wrote: >>>2 questions: >>> >>>1. Can I use the (great) dependency handling of setuptools in a windows >>>installer, eg by packing a python egg in a windows installer? >>No. It's an either-or thing. However, easy_install *can* resolve >>dependencies using bdist_wininst downloads. >> >>>2. When I make a windows installer (bdist_wininst) I assumed the windows >>>installer is python-version independent. (BTW, I use setuptools.) >>>But, when making the installer with python 2.4, and installing with >>>python 2.5, my package is installed in the right place (python 2.5), but >>>the egg-info is installed as bots-1.1.0-py2.4.egg-info. >>>As far as I can see, this is not a problem for running my application. >>It would be if something else depended on it. >> >>>But, is this how this is supposed to be? >>No. Setuptools should always mark its windows installers as Python >>version-specific, as they are not portable, even if the package >>doesn't contain extensions. >Thanks for answering >but is this an error? >in disutils? It's a setuptools error if it wrote the .exe without including py2.4 in the filename. Otherwise, it's operator error if you installed a py2.4 .exe into Python 2.5. :)

12 years, 11 months

windows installer and setuptools

by henk-jan ebbers

2 questions: 1. Can I use the (great) dependency handling of setuptools in a windows installer, eg by packing a python egg in a windows installer? 2. When I make a windows installer (bdist_wininst) I assumed the windows installer is python-version independent. (BTW, I use setuptools.) But, when making the installer with python 2.4, and installing with python 2.5, my package is installed in the right place (python 2.5), but the egg-info is installed as bots-1.1.0-py2.4.egg-info. As far as I can see, this is not a problem for running my application. But, is this how this is supposed to be? -- Kind regard, Henk-Jan Ebbers

12 years, 11 months

error with bittorrent and twisted

by andy nicholson

hi im trying to package 5.0.9 bittorrent (http://download.bittorrent.com/dl/) , as well as twisted (2.5) using setuptools. On install i get an error for bittorrent : ... Searching for BitTorrent>=5.0,<6 Reading http://download.bittorrent.com/dl/ Best match: BitTorrent 5.0.9 Downloading http://download.bittorrent.com/dl/BitTorrent-5.0.9.tar.gz Processing BitTorrent-5.0.9.tar.gz Running BitTorrent-5.0.9/setup.py -q bdist_egg --dist-dir /tmp/easy_install-7A9E17/BitTorrent-5.0.9/egg-dist-tmp-1kUjWw error: SandboxViolation: mkdir('/home/andy/.bittorrent', 511) {} The package setup script has attempted to modify files on your system that are not within the EasyInstall build area, and has been aborted. This package cannot be safely installed by EasyInstall, and may not support alternate installation locations even if you run its setup script by hand. Please inform the package's author and the EasyInstall maintainers to find out if a fix or workaround is available. -- I get another error for Twisted : Searching for Twisted>=2.5 Reading http://download.bittorrent.com/dl/ Reading http://cheeseshop.python.org/pypi/Twisted/ Reading http://twistedmatrix.com/ Reading http://cheeseshop.python.org/pypi/Twisted/2.5.0 Best match: Twisted 2.5.0 Downloading http://tmrc.mit.edu/mirror/twisted/Twisted/2.5/Twisted-2.5.0.tar.bz2 Processing Twisted-2.5.0.tar.bz2 Running Twisted-2.5.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-c7WTc2/Twisted-2.5.0/egg-dist-tmp-hIcXuu usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] or: setup.py --help [cmd1 cmd2 ...] or: setup.py --help-commands or: setup.py cmd --help error: invalid command 'bdist_egg' Error: Subprocess exited with result 1 for project core error: Setup script exited with 1 --- any hints? thanks -- Andy Nicholson +44 774 733 4891 [ .uk ] +61 406 306 715 [ .au ]

12 years, 11 months

zc.buildout and ez_setup

by Ross Patterson

A projects which using ez_setup in its setup.py as described in: http://peak.telecommunity.com/DevCenter/setuptools#id23 ...seems not to play nicely with zc.buildout. To reproduce make an empty directory and download ez_setup.py and bootstrap.py into it: http://peak.telecommunity.com/dist/ez_setup.py http://svn.zope.org/*checkout*/zc.buildout/trunk/bootstrap/bootstrap.py Then make an empty setup.py:: #!/usr/bin/env python import ez_setup ez_setup.use_setuptools() from setuptools import setup setup(name='foo') Make an empty buildout.cfg:: [buildout] develop = . Then bootstrap buildout:: $ python bootstrap.py -v Finally run buildout. Note that an error occurs importing ez_setup:: $ bin/buildout -v Installing 'zc.buildout', 'setuptools'. We have the best distribution that satisfies 'zc.buildout'. Picked: zc.buildout = 1.0.0b30 We have the best distribution that satisfies 'setuptools'. Picked: setuptools = 0.6c7 Develop: '/tmp/foo/.' Traceback (most recent call last): File "/tmp/tmpsDYTIA", line 10, in ? execfile('/tmp/foo/./setup.py') File "/tmp/foo/./setup.py", line 2, in ? import ez_setup ImportError: No module named ez_setup While: Installing. Processing develop directory '/tmp/foo/.'. An internal error occured due to a bug in either zc.buildout or in a recipe being used: AssertionError: Should I post this report anywhere else? Ross

12 years, 11 months

Enabling local distutils.cfg usage

by Tres Seaver

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 When building a virtual environment, I'd like to be able to store global distutils configuration options which are custom to that environment. However, both setuptools and distutils expect to read / write that file relative to the directory of 'distutils.__file__', which is located in the *source* environment under virtualenv 0.8.4:: $ ~/projects/source/bin/virtualenv /tmp/virtual New python executable in /tmp/virtual/bin/python Installing setuptools.............done. [/tmp] $ cd /tmp/virtual/ [/tmp/virtual] $ bin/python -c "import distutils; print distutils.__file__" /home/tseaver/projects/source/lib/python2.4/distutils/__init__.pyc The simplest way I can think of to make 'distutils.__file__' local to the virtual environment is to make an empty local 'distutils' package, which pulls in the source version by hacking '__path__'. However, because the virtual environment forces the 'real_prefix' library so high in the path, I also need to hack my own library in higher (in 'sitecustomize.py'):: [/tmp/virtual] $ patch -p1 < ../local_distutils.patch patching file lib/python2.4/distutils/__init__.py patching file lib/python2.4/sitecustomize.py [/tmp/virtual] $ bin/python -c "import distutils; print distutils.__file__" /tmp/virtual/lib/python2.4/distutils/__init__.py [/tmp/virtual] Probably it would make more sense to fix the path in the SITE_PY inside virtualenv's support-files; virtualenv could then just make the near-empty local 'distutils' package with the correct '__path__'. I have attached the patch I used to fix up the local environment ('local_distutils.patch' in the example above). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver(a)palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG+rc5+gerLs4ltQ4RAtySAKCR2RYNq/zJUnEAU/eNz5vsyYZ3ZgCeJ7lB EO0xuEmqiLKZ86ZaK3CqfeU= =r8N9 -----END PGP SIGNATURE-----

12 years, 11 months

install_recommends proposal

by Martijn Faassen

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

12 years, 11 months

setuptools development cycle

by Jim Fulton

I'm a little bit worried about setuptools development cycle. We seem to be stalled at a 0.6 pre-release that is quite stable and widely used in production. The next feature release, 0.7, seems to anticipate a major refactoring and major new features. I'm a bit worried about this both from a fear of potential disruption, and a need for incremental feature development. I propose that the grand re-factoring of setuptools planned for 0.7 be moved off the trunk and to a 2.x release. 0.6 should be marked final. Is it on the table to remove features from setuptools? If not, then I think it should setuptools should get a 1.0 release. (I do still think that setuptools, while wonderful, is too complex, so I'd love to see it simplified.) I'd then like to see incremental feature development in the 1.x line. I'd be interested in hearing Phillip's vision for setuptools' future. Jim -- Jim Fulton Zope Corporation

12 years, 11 months

Re: [Distutils] Incompatibility issue with setuptools 0.6c7-py2.4 and workingenv-0.6.5-py2.4

by Phillip J. Eby

At 10:06 AM 10/8/2007 +0300, Lauri Hallila wrote: >On 10/8/07, Lauri Hallila ><<mailto:laurihallila@gmail.com>laurihallila(a)gmail.com> wrote: >Hello! > >I noticed a small problem in setuptools... workingenv (version >0.6.5-py2.4), in some instances, adds a comment-line "# Duplicating >setuptools' site.py..." into the beginning of site.py (workingenv.py >, line 1214). Problem is that easy_install.py checks if the existing >file site.py starts with "def __boot():", and if it doesn't, it >raises an error. > >I fixed the problem in my own environment by skipping empty and >comment-lines in easy_install.py (fixed file attached). > >I just thought to inform you of the problem... feel free to take my >fix into setuptools if you like my way to fix the problem. Unless you're on a Mac, you should probably upgrade from workingenv to virtualenv: http://pypi.python.org/pypi/virtualenv/ Virtualenv does not patch setuptools, and so can't have this problem.

12 years, 11 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Distutils-SIG October 2007