I'm running on a server where I don't have root access. I've installed
my own Python into ~/py-2.5.1 (with a ~/py symlink), and created my
own ~/pylib directory for installing any extra packages I need.
I'd like to start using Easy Install / setuptools to manage package
installation, and have read the "Custom Installation Locations" --> "
"Traditional" PYTHONPATH-based Installation" section of the
EasyInstall manual (among other sections :). It's key that, if
easy_install installs prereq's, those packages end up installed in
~/pylib (since I don't have write access to any site-packages
The instructions at
http://peak.telecommunity.com/DevCenter/EasyInstall indicate that I
should probably have a ~/.pydistutils.cfg file containing either::
install_dir = /home/me/pylib
install_lib = /home/me/pylib
install_scripts = /home/me/bin
So, which one of those would be suitable for my setup? It looks like
an alternative to that would be using the ``--install-dir`` option to
easy_install every time I run it. If using ``--install-dir``, will
easy_install honor that when decending to instal dependencies as well?
Note, I've already got ~/py/bin in my PATH, PYTHONPATH is being set to
/home/me/pylib in my ~/.bash_profile, and it looks to me that,
installing packages by-hand, the correct way for my setup is::
python setup.py install --home=/home/me/pylib
So, I'm guessing that the above configurations for easy_install will
get me the same thing.
Any tips appreciated.
I'm finding myself in the following situation.
I'm writing package my.app, which encapsulates higher level concepts
specific to my application. My application runs on Plone, targeting
version 3, which runs on Zope 2.10 and sits on top of CMF 2.1.
Now, I want to depend on your.package, which provides some autonomous
functionality, say support for a particular use case or application policy.
I want to be able to get bugfixes and incremental improvements for
your.package in the future, and when other people install my.app I'd
like them to have the latest appropriate version of your.package.
Let's say your.package version 1.5 targets Plone 3 and Zope 2.10. At
this point I can't know if there'll be a 1.6 or a 1.7 or whatever also
targeting Plone 3. At some point, maybe version 2.0, maybe 1.8, maybe
4.5, it's possible that your.package will stop working on Plone 3. At
this point, someone installing my.app may inadvertently get an
incompatible version of your.package, if I have a broad (or lazy)
What I'd like to be able to say, is "I run on Plone 3, CMF 2.1, Zope
2.10, Python 2.5" -- these are my "framework" realities -- and I'd like
the latest version of your.package supporting this platform.
For that to work, your.package would need to declare such compatibility.
If it doesn't, I'd need to research and encode this in my own
install_requires. I may need to change it in the future, when the
roadmap for your.package becomes more clear.
The safe choice is possibly to declare a very narrow version
(>=1.5<1.6), at the risk of losing out on bug fixes.
But is there any support for such declarative "reverse" dependencies? Is
it something worth exploring further?
I'm currently working on a package <http://www.scipy.org/MlabWrap> making the
move from distutils to setuptools and I've got the following problem: although
the code itself should work fine out of an egg, testing requires some a
directory with some files to be created for matlab. Since it's only needed for
testing I don't want to clutter the installers HD.
How should I best handle this? Currently I'm just using ``zip_safe=False``,
but a more elegant solution would seem to be for the test-code to temporarily
unpack the relevant files from the egg into some temp-dir run the tests and
delete the temp files again. I figure other projects might face a similar
situation and I was wondering if some good solution is already available, or
if I just should hack something together.
I'm still trying to figure out how to handle versioning, including development
release versioning in a simple but automated fashion. Basically assuming svn
had some hypothetical, $Version$ tag, which would either list the user-chosen
version name, plus, if there have been changes since that has been last
assigned, a the project-wide svn-release number (e.g. "1.1" or "1.1.dev43"),
I'd just put that in setup.py, the project's __version__ = ... string in
__init__.py and ideally even the docs. No such thing exists, however and so
far I've been doing it by hand, which is clearly suboptimal, especially since
I'm also currently writing a howto for scikits authors (
<http://projects.scipy.org/scipy/scikits>, very rough at the moment) were I'd
like to give best practices.
Basically, if svn had a $Revision$ keyword that worked, I'd just use that in
setup.py and the package's __init__ (and possibly the README). Now
numpy.distutils.utils contains some code to create a __svn_version__.py file
which can then be used in conjunction with a version.py file, in which one
specifies the official version number + a release flag (true or false) to get
either "1.1" or "1.1.dev43". I've started to detail this at
<http://projects.scipy.org/scipy/scikits#version.py>, but it seems rather
clumsy and also has the disadvantage that one needs to use numpy.distutils in
addtition to setuptools, further complicating things (numpy.distutils is also
not that well documented IMO, and I haven't got the approach to work as I
So I was wondering if there wasn't maybbe a nicer way to achieve this, using
just setuptools. I've had a look at
but from that it's e.g. not clear to me how one would obtain the right
__version__ string in ``project/__init__.py``. I think I might just have
missed the right info in the docs, but I'd really appreciate it if someone
could walk me through the steps how I can specify at one place that I want to
create a proper release with version X or a development release with version
X.devY and have this info available everywhere it's needed.
[brought back on-list (forgot/didn't notice this list doesn't set Reply-To)]
On 5/13/07, Alexander Schmolck <a.schmolck(a)gmail.com> wrote:
> [did you send this off-list on purpose?]
> "Alexander Michael" <lxander.m(a)gmail.com> writes:
> > I don't think setuptools/pkg_resources/eggs are designed to handle
> > running tests like this after (end-user) installation. There is
> > support for running unittests during development as part of package
> > building. Does the end user *need* to run these tests to determine the
> > correct package configuration for their machine?
> > If not, you should probably wrap up the tests into a test suite and use the
> > setuptools test functionality
> > (<http://peak.telecommunity.com/DevCenter/setuptools#test-build-package-and-r…>)
> I do have a unitest test suite, and I'm also using the test_suite option.
> However that test suite needs to place several, exiting .m files into tempdir
> (and tell matlab about their whereabouts in order to run all the tests, but
> telling matlab is easy). I still don't see a good way do conditionally extract
> stuff from the egg for testing (I don't think ``test_suite`` does that, unless
> I'm missing something). I could obviously encode all these files as a python
> string in the testmodule and then create them manually in the tempdir or
> something similarly horrible -- sort of like a shell archive, but that strikes
> me as suboptimal.
We're getting out of my depth here. But it is my understanding that
the test command adds the source directory to the sys.path, so that
you could acquire undeclared data files the old-fashioned way (i.e.
os.path.join(mypackage.__path__, 'test-mex.c'), although you might be
able to use pkg_resources which is cleaner. Your test would copy the
test data to a tempdir, do its thing, check the result, and clean-up.
> > along with tempfile (<http://docs.python.org/lib/module-tempfile.html>),
> > otherwise I don't think (but could have missed something) that eggs support
> > running arbitrary code at install time to do such configuration (hence
> > Enthought's postinstall extensions). If the latter, perhaps someone else can
> > be of more help.
I just stumbled over the following problem, maybe someone can help me
understand whether its a problem that should be fixed in setuptools or
whether I'm misunderstanding something.
I was packaging an application (a TurboGears quickstarted project) that
has one a pure Python start script with bdist_egg. I'm using
/usr/bin/env for finding the Python interpreter in the shebang line of
the start script in order to make the whole thing as platform
independent as possible.
Now bdist_egg replaces my shebang line with the path to the python
interpreter of the build platform. I just saw that this was already
mentioned as a problem on the list recently:
I agree that this should be changed as suggested there.
Currently, even though an application may be completely platform
independent, setuptools creates "impure" eggs by putting a platform
dependent path into the scripts. I.e. I cannot package the application
on one platform and easy_installing it on a different platform.
I think the real problem is that setuptools replaces the shebang line
when *building* the egg, not when *installing* the egg. Maybe the
replacement at build time is done for backward compatibility with
distutils? But then it should be done when easy_installing as well.
i am a new in this...
how i can use stdeb to create a debian package for my
python package(my project)..
i read this (http://stdeb.python-hosting.com/)
article.. but i cant understand.. so plz help
thanks in advance.
8:00? 8:25? 8:40? Find a flick in no time
with the Yahoo! Search movie showtime shortcut.
I just fixed a bug in the zc.buildout bootstrap script:
That caused boostrapping to fail when an old setuptools was installed
in the Python path (e.g. system Python). Now, the system Python is
used if it's available and ez_setup is used only if necessary. Not
only does this avoid failures when older versions of setuptools is
installed, but also makes bootstrapping a little faster when
setuptools is installed locally.
People including bootstrap.py in their projects should update to the
Jim Fulton mailto:firstname.lastname@example.org Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.comhttp://www.zope.org