Mailman 3 April 2008 - Distutils-SIG

Re: [Distutils] [Python-Dev] shal we redefine "module" and "package"?
by glyph＠divmod.com 01 May '08

01 May '08

On 10:53 pm, steve(a)holdenweb.com wrote: >zooko wrote: >>Unfortunately these answers aren't quite right. A "package" is >>actually a directory containing an __init__.py file, and a >>distribution is actually what you think of when you say "package" -- a >>reusable package of Python code that you can, for example, get from >>the Python package index. The fact that the Python "package" index is a place where you get "distributions" does seem a bit weird to me, but this is not necessarily a problem that can be fixed. Ambiguity is part of human language. Perhaps suggest transliterations of these terms for talking about python in lojban? :) >>1. A "module" shall henceforth be the name for either a foo.py file >>(a single-file module), or a directory with an __init__.py in it (a >>directory module). I have a less disruptive counterproposal. How about just starting to refer to directories (or "folders", or zip entries) with '__init__.py' in them as "package modules"? A package is-a module anyway. >>2. A "package" shall henceforth be the name of the thing that is >>currently called a "distribution". I belive a multi-word term here would be similarly more memorable and precise. A "package distribution" would include the more familiar term while still being specific, consistent with the old terminology, and correct. Using a qualifying word is probably a good idea in this context anyway. I usually say "debian package", "RPM", "MSI", or "tarball" unless I'm specifically talking about "packages for your platform", almost always in the phrase, "please do not use distutils to do a system install of Twisted, use the specific package for your platform". >-1 I do, however, agree with Steve emphatically on your original proposal. Changing the terminology now will make billions upon billions of Python web pages, modules (c.f. twisted.python.modules.PythonModule.isPackage()) documents, and searchable message archives obsolete, not to mention that 90% of the community will probably ignore you and use the old terminology anyway, creating more confusion than it eliminates.

3 4

Setuptools Bug: all files installed +x
by Pete 01 May '08

01 May '08

On both linux & OS X, Setuptools installs all .py/.pyc files with mode a+x (executable for all users). This occurs regardless of original the permissions in the source tarball. Doing so breaks nosetests, which by default refuses to import executable files for test-discovery purposes as a safety measure. This behavior is broken & dangerous. -- Pete pfein(a)pobox.com

6 11

shal we redefine "module" and "package"?
by zooko 30 Apr '08

30 Apr '08

Folks: Here's an experiment you can perform. Round up a Python programmer and ask him the following three questions: Q1. You type "import foo" and it works. What kind of thing is foo? Q2. You go to the Python package index and download something named "bar-1.0.0.tar.gz". What kind of thing is bar? Q3. What is a "distribution"? I'm willing to bet that you will get the following answers: A1. foo is a module. A2. bar is a package. A3. A distribution is a version of Linux that comes with a lot of Free Software. Unfortunately these answers aren't quite right. A "package" is actually a directory containing an __init__.py file, and a distribution is actually what you think of when you say "package" -- a reusable package of Python code that you can, for example, get from the Python package index. Educational efforts such as the Python tutorial and the distutils docs have not succeeded in training Python programmers to understand the terminology for these things as used by the Python implementors, so perhaps instead the implementors should start using the terminology understood by the programmers: 1. A "module" shall henceforth be the name for either a foo.py file (a single-file module), or a directory with an __init__.py in it (a directory module). 2. A "package" shall henceforth be the name of the thing that is currently called a "distribution". Regards, Zooko who doesn't mind stirring up trouble on occasion...

4 3

problems bundling data with setuptools
by Michael Hearne 30 Apr '08

30 Apr '08

I'm having trouble bundling any kind of data (non-Python code) in my egg. Here are the file contents of my source directory: hello.py (cheesy script) README.txt MANIFEST.in (has one line, "include *.txt") setup.py, which looks like: from setuptools import setup, find_packages setup( name = "HelloWorld", version = "0.1", scripts=['hello.py'], include_package_data = True ) I'm creating the egg with python setup.py bdist_egg. I would expect that README.txt should appear in the egg somewhere, but it doesn't. What am I missing? Thanks, Mike ------------------------------------------------------ Michael Hearne mhearne(a)usgs.gov (303) 273-8620 USGS National Earthquake Information Center 1711 Illinois St. Golden CO 80401 Senior Software Engineer Synergetics, Inc. ------------------------------------------------------

2 3

buildout and mod_wsgi
by Martin Aspeli 29 Apr '08

29 Apr '08

Hi all, I'm trying to deploy a Repoze-based application via mod_wsgi. I'm building Repoze in a buildout. The problem is that I need to get mod_wsgi to execute the WSGI script with buildout's working set of eggs. The mod_wsgi configuration looks like this: WSGIDaemonProcess tmp threads=1 processes=4 maximum-requests=10000 python-path=/usr/lib/python2.4/site-packages <VirtualHost *:80> ServerName my.machine.local WSGIScriptAlias / /path/to/bin/zope2.wsgi WSGIProcessGroup tmp WSGIPassAuthorization On </VirtualHost> Now, this says to create a process pool of Python processes with the given python-path. This is really geared towards the virtualenv use case, where you'd have a custom virtualenv python-path for each project. In the case of buildout, however, the pythonpath is explicitly for console scripts by munging console scripts and doing sys.path manipulation. Unfortunately, zope2.wsgi is not a console script, it's just a script that contains: from paste.deploy import loadapp ini = '/path/to/pasteconfig.ini' application = loadapp('config:%s' % ini) The key here is that this is a script that needs to define a global variable 'application'. The only way I can make this work, is to paste a block of sys.path manipulation from a console script that buildout has had the opportunity to munge, but that's not exactly a stable solution. I can see the following possible solutions: 1) Make a buildout recipe that creates a directory with a .pth file for all the eggs in the working set. This would then be able to serve as a python-path above. 2) Make a buildout recipe that generates the zope2.wsgi script as above, but also generates the sys.path munging. Does one of these exist already? Is there a better way? For reference: http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonPro… Cheers, Martin

2 2

Two versions of SQLAlchemy side-by-side?
by skip＠pobox.com 29 Apr '08

29 Apr '08

We have SQLAlchemy 0.3.3 installed via setuptools. I upgraded to 0.4.5 today but had to back that out (by editing easy-install.pth) because of API changes. Now I have these two installs .../site-packages/SQLAlchemy-0.3.3-py2.4.egg .../site-packages/SQLAlchemy-0.4.5-py2.4.egg Is there a way to import the 0.4.5 version for testing without disturbing the 0.3.3 version? I tried placing the 0.4.5 egg directory in PYTHONPATH but I still get the 0.3.3 version when I "import sqlalchemy". What's a fella to do? Thanks, Skip

3 5

Re: [Distutils] virtual env with exec prefix
by Hans Meine 28 Apr '08

28 Apr '08

Hi Ian, recently I reported this problem to you: > [...] here at our university, python (as > well as hundreds of other software packages) is installed in a shared NFS > tree with a clear separation of --prefix and --exec-prefix, i.e. all > platform-specific stuff goes into the according subdirectories. [...] > [2] meine@kogspc33:~ -> virtualenv enthought-inst > New python executable in enthought-inst/bin/python > Installing setuptools.... > Complete output from command enthought-inst/bin/python -c "#!python > \"\"\"Bootstrap setuptoo... > > > > > " /software/python-2.4.4/SuSE-10...4.egg: > error: invalid Python installation: unable to > open /software/python-2.4.4/lib/python2.4/config/Makefile (No such file or > directory) > > [The message] is right, because it should be > /software/python-2.4.4/SuSE-10.2/lib/python2.4/config/Makefile > which exists (in the SuSE-10.2 directory). I have now debugged this a little bit (using virtualenv from SVN), and it seems to be a problem with the virtualenv'd python and setuptools. I have written the EZ_SETUP_PY to disk, and when I mimick virtualenv's command for installing setuptools, I get the error: [2] meine@kogspc33:~/Programming/enthought -> inst/bin/python ../ez_setup.py -v /home/meine/Programming/virtualenv-svn/support-files/setuptools-0.6c8-py2.4.egg error: invalid Python installation: unable to open /software/python-2.4.4/lib/python2.4/config/Makefile (No such file or directory) (NB: inst is the virtual env) OTOH, when I run this with the python binary from its original location, it works fine. Since the error comes from deep within setuptools (AFAICS), should this be discussed on distutils-sig? Ciao, / / /--/ / / ANS

2 3

setuptools easy_install upgrade to 0.6c8 problem
by Scott Brown 28 Apr '08

28 Apr '08

I have upgraded setuptools from http://peak.telecommunity.com/DevCenter/EasyInstall to 0.6c8, but my system keep trying to use the older version 0.6c7. If I remove the older version, then I get the error message: File "/Library/Python/2.5/site-packages/setuptools-0.6c8-py2.5.egg/pkg_resources.py", line 524, in resolve pkg_resources.DistributionNotFound: setuptools==0.6c7 when I try to run easy install. When I check the installation of the new version it says that it has already been installed: sudo python ez_setup.py Setuptools version 0.6c8 or greater has been installed. (Run "ez_setup.py -U setuptools" to reinstall or upgrade.) I am using Mac OS X 10.5. How do I completely remove all traces of the old version of setuptools and get the new version 0.6c8 recognised? Get the name you always wanted with the new y7mail email address. www.yahoo7.com.au/y7mail

2 2

Ignore ~/.pydistutils.cfg ?
by Peter Fein 26 Apr '08

26 Apr '08

is there a way to tell distutils/setuptools to ignore ~/.pydistutils.cfg? I use a config to keep easy_install'd packages in my home directory but doing so confuses MacPorts; they're apparently passing --exec/-- exec-prefix, but it seems to be getting overriden by my config. See: http://trac.macports.org/projects/macports/ticket/9831#comment :4

3 2

[ANN] stdeb 0.2
by Andrew Straw 26 Apr '08

26 Apr '08

I would like to announce the release of stdeb 0.2. = What is it? = stdeb http://stdeb.python-hosting.com/ ("setuptools debian") produces Debian source packages from Python packages via a new distutils command, sdist_dsc, which produces a Debian source package of a Python package. Automatic defaults are provided for the Debian package, but many aspects of the resulting package can be customized via a configuration file. = What's new? = This is a primarily a bug-fix release cleaning up after the alpha series which introduced many new features. Here is the detailed changelog since the last alpha release. 008-03-27 Add ability to pass environment variables to setup.py script. 2008-03-18 Do not allow '.' in source package names. 2008-01-20 Allows a user to build every dependency a package has stated on it's setup.py, recursively. 2007-10-29 Allow upstream tarball to have different name from debian .orig.tar.gz but keep md5sum. 2007-05-28 Fix bug where python distribution name contained '-' but setuptools renamed this to '_'. 2007-05-11 Fix py2dsc script to properly set __file__ and __name__. 2007-04-18 Fix bug where .egg-info renaming failed when upstream version contained '-'. = Thanks = A special thanks to Pedro Algarvio, aka s0undt3ch, for helping with this release.

2 3