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?
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.)
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. :)
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
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 ]
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.pyhttp://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
-----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-----
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
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
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.