Mailman 3 April 2008 - Distutils-SIG

Shebang lines on Jython
by Philip Jenvey April 16, 2008

April 16, 2008

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 error. For posix, we'll just need to special case Jython on posix to make a shebang along the lines of: #!/usr/bin/env /opt/local/bin/jython 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. With: #!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: \scripts\myscript-script.py" when we need: "c:\windows\system32\cmd.exe" /c ""c:\jython2.2\jython.bat" "c: \scripts\myscript-script.py"" 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? -- Philip Jenvey

2 2

ez_setup.py fails with ImportError: No module named core
by Deron Meranda April 16, 2008

April 16, 2008

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: Downloading http://pypi.python.org/packages/2.5/s/setuptools/setuptools-0.6c8-py2.5.egg Traceback (most recent call last): File "ez_setup.py", line 267, in <module> main(sys.argv[1:]) 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? -- Deron Meranda

1 1

Re: [Distutils] ez_setup.py fails with ImportError: No module named core
by Phillip J. Eby April 16, 2008

April 16, 2008

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: > >Downloading >http://pypi.python.org/packages/2.5/s/setuptools/setuptools-0.6c8-py2.5.egg >Traceback (most recent call last): > File "ez_setup.py", line 267, in <module> > main(sys.argv[1:]) > 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.

1 0

Re: [Distutils] [Python-Dev] PEP 365 (Adding the pkg_resources module)
by Phillip J. Eby April 15, 2008

April 15, 2008

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.)

9 20

shebang line modified by setuptools
by Cliff Wells April 14, 2008

April 14, 2008

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 upgrades"). 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. Regards, Cliff

1 0

Re: [Distutils] how to easily consume just the parts of eggs that are good for you
by Phillip J. Eby April 14, 2008

April 14, 2008

At 10:49 PM 4/8/2008 -0400, Stanley A. Klein wrote: >On Tue, April 8, 2008 9:37 pm, Ben Finney ><bignose+hates-spam(a)benfinney.id.au> wrote: > > 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. > The >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.

14 44

[Enthought-dev] Installation woes - again..
by Hans Meine April 14, 2008

April 14, 2008

Hi, 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 easy_install: https://mail.enthought.com/pipermail/enthought-dev/2008-April/013913.html 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: http://kogs-www.informatik.uni-hamburg.de/~meine/clean-ets-install.log ) 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, Hans

1 0

Re: [Distutils] Distutils-SIG Digest, Vol 60, Issue 29
by Stanley A. Klein April 14, 2008

April 14, 2008

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 > together. > 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. Stan Klein

1 0

how to easily consume just the parts of eggs that are good for you
by zooko April 14, 2008

April 14, 2008

Folks: 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 eggs. This is very likely forward-compatible with new schemes that are currently being cooked up and will be deployed in the future. Regards, Zooko

9 11

[issue7] Test 1
by Martin v. Löwis April 13, 2008

April 13, 2008

New submission from Martin v. Löwis <martin(a)v.loewis.de>: Testing the installation ---------- messages: 7 nosy: loewis priority: bug status: unread title: Test 1 _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue7> _______________________________________________

1 0