New submission from techtonik <techtonik(a)gmail.com>:
I would like to propose this wrapping sys.exit() calls in generated console scripts into __main__ block. This will prevent programs that inspect available modules using 'import' from exiting prematurely. See http://bitten.edgewall.org/ticket/583
title: [PATCH] wrap console script into __main__ block
Added file: http://bugs.python.org/setuptools/file68/wrap.scripts.into.main.diff
Setuptools tracker <setuptools(a)bugs.python.org>
I'm looking for case studies or other examples of management of a
development/test/build/QA/release process involving lots of Python
packages with dependencies.
At work currently, we use Hudson for running our tests, and are using
it to produce eggs, sdists, and PIP requirements files. It's shaping
up to be a nice way to build our packages, but it's about to get a lot
bigger with a lot more packages and complex dependencies. We're
working on defining processes for our developers and testers, and
we're inventing as we go.
I have a good idea where we need to go with this, but our management
wants to hear how others in the community handle this kind of
challenge with releasing multiple dependent packages together,
especially in light of workflows made possible by DVCS. (We're using
Does anyone have any stories to tell on this front?
At 11:44 AM 5/7/2010 -0700, Kent wrote:
> > > The next thing I would do is verify that the config file is
> actually being read, by setting the DISTUTILS_DEBUG environment
> variable to "yes", and then running "easy_install -v ." and
> observing the output.
>I've pasted the output here: http://pastebin.com/1it5XPAL
>Hopefully you can make sense of the output.
Yep. The issue isn't with installation-time dependencies, it's
build-time dependencies -- that's why I was confused.
There was a change to how build-time dependencies are handled,
specifically intended to fix a different issue with Paste,
PasteScript, and PasteDeploy's dependencies on each other.
My guess is that if you put eggs for those three packages in your
third-party directory, the problem (or at least the problem with
those three) would go away.
However, I'll see if there's a way for "child" easy_install runs (as
used for build-time dependencies) to inherit the parent's settings
for things like --find-links, --index-url, and --allow-hosts (but not
options that would interfere with the child install's options.
At 05:54 AM 5/7/2010 -0700, Kent wrote:
> > Does this still work if you run "easy_install ." instead of
> "setup.py install"?
>No, when I try this it attempts to download from the internet:
>while processing a dependency's dependency.
>This happens despite the fact that I have this section in setup.cfg:
>index_url = ../../thirdparty
I thought you were using --find-links as of your last email? So, I'm
a little confused as to what scenario you're actually trying to fix.
The next thing I would do is verify that the config file is actually
being read, by setting the DISTUTILS_DEBUG environment variable to
"yes", and then running "easy_install -v ." and observing the output.
>Like I mentioned, I do have a workaround in place that is working for
>me. I post it here in case it may help others:
Please don't do that, and *nobody else should do it either*. You are
going to ERASE people's personal distutils configuration files with
that code! (You're not even checking to see if it exists first!)
I would be *extremely* upset if I tried to install your package and
it erased one of my .pydistutils.cfg files, with all their command
aliases, wikiup configs, path customizations, etc.
(Of course, when run under easy_install control, the sandbox should
catch your setup script's antics and terminate it with an error
without harming any files, but still... it's pure evil and the sort
of thing that should NEVER, ever be done in a setup.py, on pain of
banishment from PyPI.)
I've cut a release of Distutils2 (that was planned for May 1st).
This release can't be used in production, is under-documented, but has
cool isolated features that can be already used in your projects:
- features added during the last year, like the "check" command
- a find_packages() function. extracted from setuptools but that can
take several root paths.
- a metadata reader/writer compatible with all metadata flavors (1.0,
1.1, 1.2) - see http://packages.python.org/Distutils2/metadata.html
- a version module that implements PEP 376 - no doc yet ;)
Also, we have implemented PEP 345 on PyPI side. You can see for
example the project urls in a box on the right side of the page.
1.0a2 - 2010-05-28 (Python 2.7rc1 and GSOC starts)
1.0b1 - 2010-06-25 (Python 2.7 final)
1.0b2 - 2010-07-17 (GSOC Mid-term)
1.0c1 - 2010-07-30 (GSOC Ends)
1.0 final - 2010-08-15
Feedback is welcome !
Tarek Ziadé | http://ziade.org
Is it me or is there trouble with the latest Buildout bootstrap file:
I get this on the latest Ubuntu when trying to run it:
aclark@ubuntu:~/Developer/plone-site-admin/buildout$ src/python-buildout/python-2.4/bin/python2.4 bootstrap.py
-> from optparse import OptionParser
23 import os, shutil, sys, tempfile, textwrap, urllib, urllib2
24 import pdb ; pdb.set_trace()
25 -> from optparse import OptionParser
27 if sys.platform == 'win32':
28 def quote(c):
29 if ' ' in c:
30 return '"%s"' % c # work around spawn lamosity on windows
32 return c
34 quote = str
36 # In order to be more robust in the face of system Pythons, we want to
37 # run without site-packages loaded. This is somewhat tricky, in
38 # particular because Python 2.6's distutils imports site, so starting
39 # with the -S flag is not sufficient. However, we'll start with that:
40 if 'site' in sys.modules:
41 # We will restart with python -S.
-> if sys.platform == 'win32':
-> quote = str
-> if 'site' in sys.modules:
-> args = sys.argv[:]
-> args[0:0] = [sys.executable, '-S']
-> args = map(quote, args)
-> os.execv(sys.executable, args)
Traceback (most recent call last):
File "bootstrap.py", line 23, in ?
import os, shutil, sys, tempfile, textwrap, urllib, urllib2
ImportError: No module named shutil
But if I revert an older bootstrap.py, the problem goes away.
Alex Clark · http://aclark.net
Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin
At 12:42 PM 5/4/2010 -0700, Kent wrote:
>To accomplish this, with version c9, I added the following lines to
>find_links = ../../thirdparty
Does this still work if you run "easy_install ." instead of "setup.py install"?
At 08:31 PM 5/6/2010 +0200, Lennart Regebro wrote:
>On Thu, May 6, 2010 at 20:14, Tarek Ziadé <ziade.tarek(a)gmail.com> wrote:
> > I am +1 to remove package_dir
>It's gonna be a pain it the ass moving all packages from src/, though.
Oh, having a src/ or lib/ root isn't a problem, IMO. I just don't
think package_dir should allow *multiple* roots.
Most people who are actually using that feature (AFAICT) are just
confused about how Python packaging is supposed to work, rather than
actually needing multiple roots.
2010/5/6 P.J. Eby <pje(a)telecommunity.com>:
> At 03:39 PM 5/6/2010 +0200, Tarek Ziadé wrote:
>> a find_packages() function. extracted from setuptools but that can
>> take several root paths.
> Darn. I was really hoping that distutils2 would enforce a *single* root
> path for packages. package_dir is an abomination that should die, die, die.
> (IMO, anyway. ;-) )
Oh well, find_package() is just a helper for the package option. The
is to make it easier to add extra packages (like a third party package
incuded in the distro)
Now for the package_dir, option, I wouldn't mind removing it. I have
always hated it too.
If we just kill it, people will just have to provide packages relative
to the root,
I am +1 to remove package_dir
Tarek Ziadé | http://ziade.org