New submission from Jeff Rush <jeff(a)taupro.com>:
Testing a bug post.
title: A Test Issue
Setuptools tracker <setuptools(a)bugs.python.org>
I'm currently struggling to find a good way for running unit tests in my
project. Adding a custom Command to my setup.py for running the tests
wouldn't be a big problem but the unit tests need a few additional
shared libraries. These libraries are simple stub files used for testing
the plugin loader I'm developing. So is there a way to tell distutils to
build those shared libraries only if want to run the unit tests?
Otherwise those libs should be ignored because I don't want them to be
Thanks for the help
is it possible to get hold of the buildout configuration of part A from
within the recipe configured for part B? Usecase: the configuration of part
A should work as blueprint for actions performed through the recipe
configured for part B.
At 12:02 PM 4/18/2008 -0400, Alexander Michael wrote:
>On Fri, Apr 18, 2008 at 10:38 AM, Chris Withers
> > Alexander Michael wrote:
> > > By default, setuptools enabled setup.py's install eggs (either zipped
> > > or unzipped) so that you can multiple version installed (but only one
> > > active, of course). If you want to install just a single version as a
> > > standard python package directory, then use the
> > > --single-version-externally-managed option as described in the
> > > documentation:
> > >
> > $ python2.4 setup.py install --home=$INSTANCE \
> > --single-version-externally-managed
> > running install
> > error: You must specify --record or --root when building system packages
> > Sadly neither the --record or --root options appear to be documented
> > anywhere...
>That is sad. There is a hint from "python setup.py install --help":
> --root install everything relative to this
> alternate root directory
> --record filename in which to record list of
> installed files
>Maybe they're provided by standard distutils? I know the seuptools
>documentation doesn't reiterate anything about distutils, just the
Correct: --root and --record are standard distutils options. In this
case, you want --record, not --root.
The reason this option requires either --root or --record, is so that
you have a way to know what was installed and uninstall it. In the
--root case, everything installed will be under a single directory
tree, and in the --record case, you'll have a list of the files.
On Fri, Apr 18, 2008 at 10:38 AM, Chris Withers <chris(a)simplistix.co.uk> wrote:
> Alexander Michael wrote:
> > By default, setuptools enabled setup.py's install eggs (either zipped
> > or unzipped) so that you can multiple version installed (but only one
> > active, of course). If you want to install just a single version as a
> > standard python package directory, then use the
> > --single-version-externally-managed option as described in the
> > documentation:
> $ python2.4 setup.py install --home=$INSTANCE \
> running install
> error: You must specify --record or --root when building system packages
> Sadly neither the --record or --root options appear to be documented
That is sad. There is a hint from "python setup.py install --help":
--root install everything relative to this
alternate root directory
--record filename in which to record list of
Maybe they're provided by standard distutils? I know the seuptools
documentation doesn't reiterate anything about distutils, just the
I'm trying to install a package into a Zope INSTANCE_HOME with:
python2.4 setup.py install --home=$INSTANCE_HOME
...however, this is leaving me with an easy-install.pth and a .egg file
in $INSTANCE_HOME, even though the package has zip_safe=False in its
Simplistix - Content Management, Zope & Python Consulting
So I've just added
to my setup() call. How do I test that from within my local source
repository? Running "python setup.py install" doesn't seem to do anything
with it (I didn't expect it to). I assume I have to get easy_install to
process the setup.py file in the current directory somehow, but I don't see
Greg Ewing wrote:
> When you go into a computer store and ask for
> 256MB of RAM, you don't expect to be asked "What size
> bytes would that be, then, sir?"
I ask for "256 Mo", Mo for Mega-octet: French (and most non English
languages I am aware of) does not have this ambiguity :) And anyway, in
a computer store, you find memory for personal computers, where one byte
always has 8 bits.
> So it's a de facto standard, and one that works perfectly
> well. Going against it is both futile and unnecessary,
> as far as I can see.
Going against the C standard seems pretty futile to me.
In setuptools.command.bdist_egg:write_stub() Setuptools writes this
function out alongside .so files:
global __bootstrap__, __loader__, __file__
import sys, pkg_resources, imp
__file__ = pkg_resources.resource_filename(__name__,<resource filename>)
del __bootstrap__, __loader__
This is problematic on App Engine, as the .py file is loaded because .so
files cannot be imported. However, unlike a zip file (where I assume
this function is intended to be used) there is no __loader__. As a
result "del __loader__" fails.
I submitted this to App Engine
(http://code.google.com/p/googleappengine/issues/detail?id=229), but I
also think Setuptools is creating an unnecessarily fragile function here.
Ian Bicking : ianb(a)colorstudy.com : http://blog.ianbicking.org