Speaking of shebang lines, there's problems with setuptools shebang
lines on Jython. Unfortunately it's going to require another patch or
two to setuptools.
The problem being that Jython's executable is a .sh or .bat file
(that'll invoke java), and interpreters in shebang lines can't be
interpreter files, i.e. another script. Running a .py script that
shebangs the Jython .sh executable directly will result in something
along the lines of a "test.py: line 2 import command not found" sh
For posix, we'll just need to special case Jython on posix to make a
shebang along the lines of:
Windows isn't as easy. setuptools' launcher.c similarly can't use
a .bat file as the interpreter. A workaround would be to use cmd.exe /
c in the same way we'll use /usr/bin/env on posix. launcher.c
currently can't handle this, though, the problem being it can't
correctly quote the cmd.exe /c line correctly.
#!c:\windows\system32\cmd.exe /c c:\jython2.2\jython.bat
launcher.c ends up calling:
"c:\windows\system32\cmd.exe" "/c" "c:\jython2.2\jython.bat" "c:
when we need:
"c:\windows\system32\cmd.exe" /c ""c:\jython2.2\jython.bat" "c:
which is another set of quotes around the entire /c arg, and yes no
quotes around /c (I have no idea why "/c" doesn't work).
I guess we would have to patch launcher.c to deal with this special
situation or make a custom version for Jython. That's pretty awful --
might anyone have a simpler way of handling this?
For some reason I can not bootstrap setuptools 0.6c8 into a python.
This is Python 2.5 running under AIX 5.2, and the site-packages
directory is completely empty. I've tried to use just ez_setup.py
with no options, as well as downloading the egg file locally into
a temporary directory and using:
python ez_setup.py -v -H "" setuptools-0.6c8-py2.5.egg
I get this strange traceback every time:
Traceback (most recent call last):
File "ez_setup.py", line 267, in <module>
File "ez_setup.py", line 200, in main
from setuptools.command.easy_install import main
File "build/bdist.linux-i686/egg/setuptools/__init__.py", line 2, in <module>
File "build/bdist.linux-i686/egg/setuptools/extension.py", line 1, in <module>
ImportError: No module named core
Furthermore, the local egg file setuptools-0.6c8-py2.5.egg is
removed from my working directory! My working directory is
completely outside of the python path or site-packages dir.
I also tried using the -d option to explicitly point to the site-packages
dir, but the results are the same.
I can not figure out what exactly is wrong. Any ideas?
At 03:42 PM 4/16/2008 -0400, Deron Meranda wrote:
>For some reason I can not bootstrap setuptools 0.6c8 into a python.
>This is Python 2.5 running under AIX 5.2, and the site-packages
>directory is completely empty. I've tried to use just ez_setup.py
>with no options, as well as downloading the egg file locally into
>a temporary directory and using:
> python ez_setup.py -v -H "" setuptools-0.6c8-py2.5.egg
>I get this strange traceback every time:
>Traceback (most recent call last):
> File "ez_setup.py", line 267, in <module>
> File "ez_setup.py", line 200, in main
> from setuptools.command.easy_install import main
> File "build/bdist.linux-i686/egg/setuptools/__init__.py", line 2,
> in <module>
> File "build/bdist.linux-i686/egg/setuptools/extension.py", line
> 1, in <module>
>ImportError: No module named core
This is an indication that your distutils installation is broken
and/or missing. Make sure that if your OS has a 'python-dev' or
'python-devel' or 'python-distutils' package, that it's installed.
At 10:53 AM 3/17/2008 -0500, Guido van Rossum wrote:
>I don't think this should play games with scripts being overridden or
>whatever. If a bootstrap script is to be installed it should have a
>separate name. I'm not sure what the advantage is of a bootstrap
>script over "python -m bootstrap_module ..." though.
And -m also makes explicit:
1. that it's a Python-specific tool
2. which Python version it will apply to
>The PEP suggests that other package managers also benefit. How do they
>benefit if the bootstrap script installs setuptools?
Because those other package managers depend, in fact, on setuptools,
or at least pkg_resources... which was why the original proposal was
to just include pkg_resources in the first place. :)
>I'd also like to avoid the specific name "easy_install" for any of
>this. That's a "brand name" (and a misleading one if you ask me, but
>that's politics again :-).
Ok, so if someone will propose a name and API for the thing, I'll
implement it. (Assuming the proposed API is sane and reasonably
implementable, of course.)
Sorry for breaking up the thread. I wasn't subscribed to the list (now
I am) and apparently I stopped being CC'd at some point, so I'll have to
sum up several things and address them here.
1) I agree that "system" scripts should use the "system" python
(whatever that is defined to mean - for now it means /usr/bin/python)
and that path should be hardcoded into the shebang line.
2) I disagree with Ben's position that:
It's my position that the Python instance one uses for development
should diverge as little as possible from the default system instance.
Otherwise one is actively pursuing a recipe for dependency failures
when one eventually deploys the result.
The reason I disagree is that assumes the system is single user and/or
single purpose. In my case (and many others) I'm concerned about a
traditional shared hosting environment (not VPS). This means that there
may be several versions of Python (and many, many
~/python2.x/site-packages directories). Diverging from the default
system instance *in every single case* is the only way to make this
workable. Not only do different accounts require a particular version
of Python, but they require particular versions of installed packages
(one might rely on Pylons 0.9.5 another on Pylons 0.9.7).
3) Since there is so much opposition to using /usr/bin/env in the
shebang line, an acceptable alternative would be to hardcode the
version-specific python instead (e.g. /usr/bin/python2.4). This seems
to solve my particular issue while respecting Phillip's concerns about
accidentally running an incorrect interpreter, and actually does a
better job since Phillip's method (using /usr/bin/python) falsely
assumes that the system Python will never change (untrue on Gentoo,
Foresight, SourceMage and any other distro that supports "rolling
4) As far as the discussion about having three separate install areas, I
think this is not necessary since it's already possible to have
unlimited install areas (one per user) using features already built into
setuptools. /usr/bin/python/ and /usr/local/bin/pythonX.X/ should
suffice. If setuptools used versioning info along with a hardcoded path
in the shebang line, this would become even more solid.
I should also mention that some of this discussion is being made moot by
virtualenv. I'll be using that for future stuff, but I have legacy
installs to worry about as well.
At 10:49 PM 4/8/2008 -0400, Stanley A. Klein wrote:
>On Tue, April 8, 2008 9:37 pm, Ben Finney
> > Date: Wed, 09 Apr 2008 11:37:07 +1000
> > From: Ben Finney <bignose+hates-spam(a)benfinney.id.au>
> > Subject: Re: [Distutils] how to easily consume just the parts of eggs
> > that are good for you
> > To: Distutils-Sig(a)Python.Org
> > zooko <zooko(a)zooko.com> writes:
> >> eyes and said "So they are planning to reinvent apt!".
> > That's pretty much my reaction, too.
>I have the same reaction.
I'm curious. Have any of you actually read PEP 262 in any detail? I
have seen precious little discussion so far that doesn't appear to be
based on significant misunderstandings of either the purpose of
reviving the PEP, or the mechanics of its proposed implementation.
>I have tried in the past to use easy_install, but have run into problems
>because there is no communication between easy_install and the rpm
>database, resulting in failure of easy_install to recognize that
>dependencies have already been installed using rpms.
This problem doesn't exist with Python 2.5, unless you're using a
platform that willfully strips out the installation information that
Python 2.5 provides for these packages.
>A database focused only on Python packages is highly inappropriate for
>Linux systems, violates the Linux standards, and creates problems because
>eggs are not coordinated with the operating system package manager.
The revamp of PEP 262 is aimed at removing .egg files and directories
from the process, by allowing system packagers to tell Python what
files belong to them and should not be messed with. And conversely,
allowing systems and installation targets *without* package managers
to safely manage their Python installations.
>way to achieve a database for Python would be to provide tools for
>conversion of eggs to rpms and debs,
Such tools already exist, although the conversion takes place from
source distributions rather than egg distributions.
>to have eggs support conformance to
>the LSB and FHS,
Applying LSB and FHS to the innards of Python packages makes as much
sense as applying them to the contents of Java .jar files -- i.e.,
none. If it's unchanging data that's part of a program or library,
then it's a program or library, just like static data declared in a C
program or library. Whether the file extension is .py, .so, or even
.png is irrelevant.
Dave P. has recently cross-posted here a mail from the enthought-dev thread I
started, in which I describe serious problems installing the ETS with
I have tried setuptools 0.6_rc8 as distributed with Gentoo, 0.6_rc7 as
installed by virtualenv, 0.6_rc8 as installed with ez_setup.py, and finally
setuptools from SVN. I am getting really strange errors which others
confirmed not to make much sense; please see the above description or the
follow-up posts. (A detailed log is here:
I have worked around this specific problem for me, but I herewith offer to
provide additional information in case anyone wants to get this fixed.
Have a nice day,
On Mon, April 14, 2008 1:37 am, distutils-sig-request(a)python.org wrote:
> Message: 4
> Date: Mon, 14 Apr 2008 14:16:13 +1200
> From: Greg Ewing <greg.ewing(a)canterbury.ac.nz>
> Subject: Re: [Distutils] how to easily consume just the parts of eggs
> that are good for you
> To: distutils-sig(a)python.org
> David Cournapeau wrote:
>> There are two ways of looking at it, I think. One is to think that linux
>> FHS (and unix in general) is totally broken.
> I don't think it's *totally* broken. I do think it goes
> overboard with splitting things up and scattering them
> around. I understand that there are reasons for some of
> that, but I don't see why e.g. includes, library files
> and other resources used by a package can't be kept
Linux and the FHS aren't broken at all. They are just designed around a
different concept than the single-user, proprietary software concept that
Windows and Mac OS X are based on. They are based on multi-user systems
with reusable software and multi-use software tools. They provide a
natural environment for community developed and maintained
Free/Open-Source Software (FOSS).
You can think of Linux splitting things up and scattering them around. I
think of Windows putting things that don't belong together in the same
place just because they happen to be supplied by the same provider. Every
Windows application is monolithic, because a proprietary provider who
depends on something other than the OS buys it, pays the royalties for its
use, hides it from the user by compiling it into the application binary,
and includes it in the software package supplied.
This doesn't usually happen in Unix or Linux. Providers depend on each
other. That's the reason for dependencies. Trying to use FOSS on Windows
creates issues that have to be addressed.
BTW, if eggs are analogous to jars (as Eby states), eggs are absolutely
not a complete packaging system and were never intended to be so. If you
look at a java-related rpm package, you are likely to see a number of jar
files along with a lot of other files.
Here is a simple proposal: make the standard Python "import"
mechanism notice eggs on the PYTHONPATH and insert them (into the
*same* location) on the sys.path.
This eliminates the #1 problem with eggs -- that they don't easily
work when installing them into places other than your site-packages
and that if you allow any of them to be installed on your system then
they take precedence over your non-egg packages even you explicitly
put those other packages earlier in your PYTHONPATH. (That latter
behavior is very disagreeable to more than a few prorgammers.)
This also preserves most of the value of eggs for many use cases.
This is backward-compatible with most current use cases that rely on
This is very likely forward-compatible with new schemes that are
currently being cooked up and will be deployed in the future.
New submission from Martin v. Löwis <martin(a)v.loewis.de>:
Testing the installation
title: Test 1
Setuptools tracker <setuptools(a)bugs.python.org>