On 10:53 pm, steve(a)holdenweb.com 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
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
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.
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.
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
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
2. A "package" shall henceforth be the name of the thing that is
currently called a "distribution".
who doesn't mind stirring up trouble on occasion...
I'm having trouble bundling any kind of data (non-Python code) in my
Here are the file contents of my source directory:
hello.py (cheesy script)
MANIFEST.in (has one line, "include *.txt")
setup.py, which looks like:
from setuptools import setup, find_packages
name = "HelloWorld",
version = "0.1",
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
What am I missing?
USGS National Earthquake Information Center
1711 Illinois St. Golden CO 80401
Senior Software Engineer
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
WSGIScriptAlias / /path/to/bin/zope2.wsgi
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
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
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?
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
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?
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. [...]
>  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
> [The message] is right, because it should be
> 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:
 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
(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
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
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.
is there a way to tell distutils/setuptools to ignore
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
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
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.