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..
I'd like to get rid of the "paster" script, moving some of what it does
into setup.py or elsewhere.
To a degree that is possible, but I think requires some additions to
* An entry point group that is not globally looked up, like
distutils.commands. This would be a set of commands the package
provides only for itself. I expect it to look like:
sql_record = sqlobject.manage.distextension:sql_record
Exactly like what we have currently, just not looked up globally.
* Additionally, or probably even better, something that enumerates
locations for commands. E.g.:
And then it would look in the SQLObject egg for
distutils.commands.local, and apply everything found there to this
package. Right now, for instance, buildutils adds a "pytest" command to
every project, even though it only applies to some projects (for some
commands this is ok, like "info", so two different entry points makes
sense). A project could list itself to provide its own custom commands;
I think that won't be too circular. Typically commands you provide for
yourself or someone else are different -- e.g., the SQLObject commands
don't apply to SQLObject itself.
* Everything that can be done on a deployed egg will probably go in
app/egg-specific command-line scripts, and maybe I'll make a little
framework to make these easier to write, but that's entirely an
implementation detail. But I'm also thinking that extra_commands could
be used as a hint to that framework, and would kind of facilitate
coordination of in-development commands with after-deployment commands.
Ian Bicking / ianb(a)colorstudy.com / http://blog.ianbicking.org
Does anyone have any experience using PyGraphViz or GraphViz on windows
with python? We are having some trouble with compiling and wonder if
anyone has had previous experience with this.
Beyond just the compilation does anyone have any experience using
PyGraphVix with PyQt? We are interested in the level of interactivity
that can be achieved with the combination of the packages.
Please e-mail back directly. Thanks!
At 10:33 PM 3/29/2006 -0500, Kurt Schwehr wrote:
>I think I have it figured out. Fink requires installing a package in a
>temporary root install that is then turned into a deb. This makes the pth
>files have bad paths.
And if you use --single-version-externally-managed as well as --root, then
it will not have bad paths. Also, 0.6a11 uses relative paths, and in any
case defaults to using --single-version-externally-managed when you specify
>If I manage the paths in the pth files after the install, then things seem
>to work. It looks like i will have to manage the easy_install.pth anyway
>since if it ends up in a deb, then other packages can't work with it. I'm
>going to create PostInstall, PostRm commands to take care of that.
Don't go to all that trouble, it's not necessary. Just use 0.6a11 with
"install --root" and you won't have to worry about any of this. If you run
into any problems with it, let me know, as 0.6a11 is supposed to "Just
Work" for system packagers using --root. If it doesn't, it's my fault, so
tell me and I'll fix it. :)
At 06:42 PM 3/29/2006 -0500, Kurt Schwehr wrote:
>Phillip and others,
>Does this look like it is installed correctly? Or is it that I am calling
>setup.py when I should be calling ez_setup? And what should I pass to
>ez_setup? It does look like setuptools are installed incorrectly since
>easy_install -h does not run. So what is the right way?
If you are packaging setuptools for use with a system packager, you should use:
python setup.py install --root=/some/pseudoroot
If you are using setuptools 0.6a10 or earlier, you *also* need
--single-version-externally-managed for this to work. 0.6a11 (which I just
released a few minutes ago) automatically sets
--single-version-externally-managed if you specify a --root, so you might
want to just go ahead and upgrade, especially since 0.6a11 has a lot of
other changes to improve compatibility with system packagers.
For example, while 0.6a10 will complain about system-installed versions of
a package as conflicting with a package that is being installed, 0.6a11
installs things such that there are no conflicts. 0.6a11 also supports
making system packages for projects containing namespace packages, without
causing inter-package conflicts for the packaging system.
This is a major new feature and bugfix release of setuptools, including:
* Overhauled conflict management: no more -D/--ignore-conflicts-at-my-risk
junk, it Just Works(TM).
* Namespace package support that's compatible with system packagers
* Lots of new setup() features including dependency_links (thanks to Tres
Seaver), test_loader, and enhanced test_suite finder
* Upload supports --identity (thanks to Stefan Behnel)
* Improved error messages for unwritable cache directory, and added a
special exception for wrapping such errors
* Revision control plugin support
* And a ton of minor bugfixes and creature comforts/"fit-and-finish"
issues, ranging from version-specific "easy_install-2.x" executables to
relative paths in .pth files.
Please see the docs for details.
Barring any new bugs, this should be the last 0.6 alpha release before we
go beta. The 0.6 beta branch will then become a candidate for inclusion in
Python 2.5 alpha 2, sometime in the next few weeks. So please report any
issues as soon as practical.
Thank you to everyone who reported problems, asked questions, and supplied
At 10:40 AM 3/29/2006 -0500, Kurt Schwehr wrote:
>This makes me think setup tools is ok since it is in the default
>Python 2.4.2 (#1, Feb 24 2006, 17:05:21)
>[GCC 4.0.1 (Apple Computer, Inc. build 5247)] on darwin
>Type "help", "copyright", "credits" or "license" for more information.
> >>> from ez_setup import use_setuptools
You didn't *call* use_setuptools, or import setuptools itself, so this
doesn't actually mean that setuptools is okay. The error message below is
displayed when use_setuptools() is *called*, not when it's imported.
My guess is that setuptools isn't actually on the path, either because it
didn't install correctly, or because the configuration for building
SQLAlchemy doesn't specify that its build requires setuptools.
>But then the SQLAlchemy build tries to pull down setuptools, which I don't
>want it to do:
>CC=gcc-3.3 /sw/bin/python2.4 setup.py build
>This script requires setuptools version 0.6a5 to run (even to display
>help). I will attempt to download it for you (from
>you may need to enable firewall access for this script first.
>I will start the download in 15 seconds.
I've just added a ``test_loader`` keyword argument to ``setup()`` in
setuptools' Subversion edition. This lets you specify a string of the form
"modulename:classname" to specify an alternative to unittest:TestLoader for
Note that an instance of the specified class will receive a name that comes
from the ``test_suite`` argument, but it is free to interpret that string
in any way it wishes. For example, a "nose" loader class could be created
that parses command line arguments from the test_suite string.
The default test_loader is "setuptools.command.test:ScanningLoader", which
scans submodules/subpackages for tests as well as invoking any module-level
"additional_tests()" functions it finds. You can use a test_loader of
"unittest:TestLoader" to force the old (non-scanning) behavior. And of
course the field is wide open for people to create new test loaders, or
wrap other testing frameworks as test loaders.
Please see setuptools.txt in the source, under the "New and Changed
``setup()`` Keywords" section, for more details on the ``test_loader`` argument.