Firstly, I would like to say thanks for the setuptools package, which
I was introduced to after reading about the RuleDispatch package on
the IBM developerworks charming python series. Oh btw. RuleDispatch is
the most useful python package that I have seen in the last year in
the python world, so thanks for that also ;)
Now that the congrats and hugs are out of the way, I would like to ask
a question. How can I tell setuptools not to put packages, such as
dispatch, protocols, and setuptools, in a subdirectory named the same
as the egg and to just put the package name.
For example from pydoc I currently get:
what I would like to see is just:
Maybe it is just a pet-peeve, but I like to keep a nice tidy
site-packages directory, and these long directory names just seem to
me to be pollution of my site-packages directory in my command shell.
If there is an option to have just the packages, I would really
appreciate someone telling me what it is. If not maybe it could be
considered, and to put whatever meta-data the directory names are
providing somewhere else..
At 11:05 PM 12/29/2005 +0800, Jeff Pitman wrote:
>I see that --single-version-externally-managed has been added as an
>option so that .deb/.rpm packaging can take advantage of that relying
>upon apt/yum/smart to take care of business. Hopefully, this will be
>pushed out soon.
FYI, unless there's some policy preventing it, you can use the current SVN
snapshot as a basis for a Debian package of setuptools. If built from a
source checkout, it will correctly include its Subversion revision number
as part of its name, e.g. "0.6a9dev-r41780". In setuptools' version
numbering, this is an *older* release than "0.6a9", so when the final 0.6a9
comes out it will replace the "dev" versions. I realize that this isn't
necessarily the same thing as how Debian package versions work, but I
assume it must have some facility for pre-release tags. If all else fails,
you could treat it as "0.6a8-r41780" instead, which might be a more
compatible numbering approach.
At this point, the only thing left on my to-do list for 0.6a9 is more
documentation for EasyInstall, so don't let that stop you from packaging
it. The only reason to wait would be to see if anybody reports bugs with
the current version, which probably won't happen until *after* 0.6a9 is
At 11:26 PM 12/31/2005 +0800, Jeff Pitman wrote:
>What's ambiguous? Unless distutils allows `-' in Version, I believe Name
>and Version can easily be extractable without transposition. Do you have a
>specific example that's not obvious?
The distutils allow *anything* in both name and version; the arguments
aren't checked in any way. Take a quick skim through PyPI and see how many
packages have a '-' in either the name or the version number. I don't know
of any that do both.
An obvious example: CherryPy 2.1.0-rc2 had a '-' in the version number. I
know of at least one other project that uses '-rc' suffixes on its
versions, though its name escapes my recall at the moment. There are also
distutils projects that have numbers in their names - distinct from the
actual version number.
At 04:35 PM 12/31/2005 +0800, Jeff Pitman wrote:
>What's the purpose of transposition between `-' and `_'? -- -jeff
The distutils put '-' between different parts of the filenames it
generates. If dashes aren't escaped, it prevents the filename from being
unambiguously parseable by a computer. As it is, when looking for source
distributions or win32.exe files, EasyInstall has to treat filenames as
having every possible ambiguous interpretation, since the distutils
currently generate such ambiguous filenames for non-setuptools projects.
At 11:45 AM 12/31/2005 +0800, Jeff Pitman wrote:
>There is a standard regular expression that can be used to split out N-V
>which is a pretty common thing in deb/rpm. (ie. python-foo). I use the
>following in some py scripts to manage these pairings for my rpm repo:
>'(?i)(.*)-([^-]*)-(([^-]*)\.([^-]*)\.%s)(.*)' Which is N-V-R.dist.repo.ext
>The form that you might want would be: '(.*)-([^-]*)' Name-Version This
>would allow Name to have -. Obviously, - cannot be used in Version. Also,
>two side notes, 1) it's kind of annoying that package names interchange
>between `-' and `_', one in the file name of the archive and one used in
>the extracted directory name. 2) I've also see the use of `_' in
>versioning, such as json.py. I also highly discourage that practice. -- -jeff
The format used by setuptools condenses non-alphanumeric runs to a single
'-' in the project's actual name and version; these are then transposed to
a '_' in filenames, with '-' to separate name parts. The canonical form is
'-', but the .egg-info directory format previously didn't transpose it to
'_'. This caused a problem when support for versioned .egg-info was added
to support system packages. I didn't realize that the setup-directory
.egg-info wasn't being translated. Anyway, this is fixed now in the SVN
version; all of the other places in setuptools that worked with '-'/'_'
filenames were using the same (correct) code to do the processing. The
relevant .egg-info code, however, was different, because it needed to *not*
include the version number, so it couldn't use the standard dist.egg_name()
method to generate a properly escaped filename including the version,
Python version, etc.
The email was deleted by system policy.
Attached file might be containing virus.
Connection From: 127.0.0.1
To: stephen.clarke(a)superh.com, joern.rennecke(a)superh.com
Date: Sat, 31 Dec 2005 17:28:04 +0900
Subject: hi, ive a new mail address
--- Scan information follows ---
Virus Name: W32.Sober.X@mm!zip
File Attachment: mailtext.zip
Attachment Status: infected
Virus Name: W32.Sober.X@mm
File Attachment: mailtext.zip/File-packed_dataInfo.exe
Attachment Status: infected
--- File name Block information follows ---
File Attachment: mailtext.zip
Matching file name: Message is considered to be a mass-mailer.
The following text is Japanese.
At 10:04 AM 12/30/2005 -0500, Kevin Dangoor wrote:
>The "tg-admin sql" command uses sqlobject which, in turn uses egg
>metadata. Something I just noticed is that these commands are no
>longer working on a project i have called "Wiki-20". They *used* to
>work. Now they get a "DistributionNotFound" error for Wiki-20.
>I had also tried to just do "pkg_resources.require("WIki-20")" from
>the Python shell, but that didn't work either. This is new behavior
>between a8 and a9. Let me know if there's anything else I can tell you
>about the problem...
Hi all. Due to the recent addition of versioned '.egg-info' support for
system packages, you may have to rename any current '.egg-info' if your
project name has a '-' in it. Otherwise, recent versions of setuptools
will think the '-' is the separator between the project name and version
number, leading to problems like the ones described by Kevin above.
I've added code to the latest SVN setuptools to detect this problem and
warn you about it, as well as tell you what you should rename the .egg-info
If you have a '-' in your project's name, and you are using an 0.6a9dev
version of setuptools, you should upgrade and rename the .egg-info
directory. If you distribute any source releases of your project or have
users tracking SVN or CVS releases of it, you *must* make your project
require setuptools>=0.6a9dev_r41857, by passing it to ez_setup, e.g.::
from ez_setup import use_setuptools
If you do not do this, and a user has an older version of setuptools, they
will encounter problems.
If you wait for the official release of 0.6a9 to upgrade, and you use its
ez_setup.py or ez_setup/__init__.py, you can avoid having to change the
setup script as shown.
Again, all this applies only to projects with a '-' in their names, and
only if *you* are upgrading from 0.6a8 to an 0.6a9 development or final
release. Your project's users can upgrade to 0.6a9 without breakage, as
there is a backward compatibility mode for everything but "setup.py
develop" (which will refuse to run until the .egg-info directory has been
I have SuSE 10.0 installed on my machine, and it comes with Python 2.4.1.
I've been trying to build Zope on this box, and I'm getting an error that it
can't find distutils.cmd. I did some digging, and it appears this is part of
distutils.core, and according to the distutils download page, distutils
should be already included with Python versions above 1.6.
I checked where my system has Python installed, and it's
at /usr/lib/python2.4. I did a find for that directory and all the
subdirectories for anything distutils, and nothing came back.
Is it just a straightforward thing to download the distutils tar file and
install it, or since it wasn't included with my Python install (and should
have been), is there anything special I should check or be aware of?
I'm still finding it impossible to use multiple versions of a package
unless none of them show up in a .pth file (i.e., none are available
without requiring), I get a VersionConflict. I think this may be
because I iterate over entry points early on, then do a require later.
Conversely, if I don't have a default version installed, I don't see any
entry points while iterating until the package is required. I can kind
of resolve this by adding a --require option to any command that uses
plugins, but this feels like I'm going down the path of CLASSPATH-like
I'm not even sure what the resolution would or can be, except that it
means that I don't see any way to reasonably use versioning and plugins
together. This worries me, since I have lots of code that is both
package and plugin, and if this is the situation then I'll have to move
to non-root installs everywhere I want version isolation. (Which I
actually suspect I'll have to do anyway, but I was hoping that things
would at least be usable without it).
Ian Bicking / ianb(a)colorstudy.com / http://blog.ianbicking.org
At 11:11 AM 12/29/2005 -0500, Kevin Dangoor wrote:
>On 12/29/05, Jeff Pitman <jeff.pitman(a)gmail.com> wrote:
> > So, they're plugins that extend tg-admin commands. In the .rpm/.deb
> > space what would happen here is that these plugins would also be
> > installed as .rpm/.deb. This is kind of like Twisted 2.0+ after the
> > split. What would be good here is to have .eggs install into $HOME and
> > tg-admin still pickup on them.
>If the system is set up correctly, the users could install the plugins
>as .rpms/.debs *or* install the eggs to their $HOME. Either way should
By the way, what Jeff is asking for regarding $HOME is now a documented
procedure in the EasyInstall documentation, known as an "Administrator
for more details.