For unittest2 I now have three different distributions. A "version" that
supports Python 2.4 - 2.7, one for Python 2.3 that is developed in a
separate branch because it makes the code ugly, and a separate distribution
for Python 3.
The reason I'm not using 2to3 with a single codebase is that unittest2 for
Python 3 is *basically* just a straight copy of the unittest package from
Python 3.2 (with a few fixes to work in 3.0 and a few other changes that are
in unittest2 anyway). Having a single distribution with multiple versions in
and having setup.py decide at install time would be another approach, but
that plays badly with test discovery.
So the challenge is, how do I put all of these up on PyPI and have pip
install the right one?
pip doesn't make it clear what versions of Python it supports, and the PyPI
page doesn't use the trove classifiers (naughty!), but I'm fine with users
of the Python 2.3 distribution having to download and install manually.
Unfortunately it *seems* that "pip install unittest2" (on Python 2.4 - 2.7)
will just install from whichever file was *most recently uploaded* to the
PyPI page - even if it is marked as not a source distribution and has Python
2.3 in the name. So, the good news is that if you've used pip to install
unittest2 in the last few days you've got the Python 2.3 version. It is
feature complete with tests, so that shouldn't actually be a problem.
As far as I can tell the only way I can solve this is to remove the Python
2.3 download from PyPI and host it separately, which is what I've now done.
(Download link on the PyPI page if you need it.)
Similarly I guess there is no way to have a Python 3 distribution under the
same project and have pip install the correct distribution under the correct
version of Python.
To get round this I have created a separate project: unittest2py3k. It still
installs the same *package name*, just has a different project name.
Now if distutils2 could solve these problems, that would be great. :-) I'm
aware that setuptools / distribute allows you to provide (what are
effectively binary) distributions for specific Python versions, but I need
to support pip too.
It would also be great if there was a way of specifying "this distribution
is for Python 2.4 - 2.7", or even "any version of Python 2 after 2.4".
All the best,
I've been waiting for years for a release of buildout that contains
proper isolation from Python's site-packages. The non-isolation is a
major flaw in buildout that makes it SO much harder to write proper
installation instructions for software such as Grok.
We need to wrap Grok's buildout installation using virtualenv
--no-site-packages. I just discovered that this installation actually
fails if I use an ubuntu-installed virtualenv (or setuptools)! It works
with a manually installed version of either, and I'm sure the problem is
somewhere in z3c.autoinclude too, but it's still an issue.
Last year in september I hacked up some code that would do the
isolation. I was then informed that Gary Poster was working on a branch
instead, and indeed the branch I saw then looked much improved in
features. So I waited. I saw new versions of the branch come and go and
I'm not sure what's going on, but I waited.
I noticed that in april there was a beta release of buildout that
featured such improvements. This release was then withdrawn and
overridden with 1.50b2 with the message:
"This is a re-release of 1.4.3 to hide the brown-bag release of 1.5.0b1.
The changes in 1.5.0b1 will reappear as 1.5.0 soon, when the additional
reported problems have been addressed."
It is now july, so I'm starting to get my doubts about the word "soon".
Have the reported problems been addressed? Is there any hope I can get a
buildout that actually provides proper isolation sometime? Can I help?
I'm wondering if there's a way to have something like "local"
buildout.cfg files overriding a "master" one; e.g.
if buildout.cfg is something like
parts = one
I'd like to have something like buildout.cfg.local and insert something like
And have the "one" section of buildout.cfg.local override what's set in
buildout.cfg, so that buildout acts like
parts = one
had been found.
This would be useful because in our projects we usually share one
per-project buildout.cfg which every team member uses and it's stored on
our VCS, and it's used all around including along our CI server, and we
don't want to change it if a real configuration change is unneeded, but
often I need to tinker with it (e.g. I want to use one additional
development egg, or change a dep, or run a different recipe).
Hence I'd like to have the chance to read a buildout.cfg.local - which I
could add into the ignore list of our VCS, be it svn, hg or whatever -
and leave the master buildout.cfg untouched.
Can I do it? If I can't right now, I'll be happy to code and submit a
patch. Any thoughts on what's the right approach? e.g. convention-based
naming (buildout.cfg.local.001 in the same dir as buildout.cfg, etc).
contact me at public(a)[mysurname].eu
I am using distribute and python 3.2a0 while I add py3k support to pip
this GSoC and I got a problem using distribute:
from distutils.sysconfig import _config_vars
ImportError: cannot import name _config_vars
Well, in Python 3 the distutils.sysconfig pops a DeprecationWarning,
because now Python has sysconfig module.
As _config_vars is very specific and 2to3 can't convert it, I suggest
using some kind of try/except in the source code, like:
from distutils.sysconfig import _config_vars
from sysconfig import _CONFIG_VARS as _config_vars
I forked distribute project in bitbucket and added this bugfix, check
it here: http://bitbucket.org/hltbra/distribute/changeset/002cccf004e6
I would like to use distribute with this bugfix asap, so, please,
upload it to PyPI :)
I've been making a buildout.cfg for deploying web sites and hit some snags.
django-page-cms is a package I want, and getting it via buildout
found eggs for other apps, but needed source for django-page-cms.
From there, some requirements, (don't know where they are in the code),
pulled in packages django-haystack, django-messages, whoosh, django-mptt-2,
I think to build the source only absolutely requires django-mptt-2.
whoosh and coverage have had problems. buildout found whoosh as
a zipped egg and left it zipped even though putting it in the common eggs
directory where all others are unzipped and a python path points to them
for use when code runs. To get a complete build, I manually unzipped.
I'm not moving eggs and downloads to my server, so buildout on the
server needed the same treatment.
coverage was found OK from my local machine, but not from the server.
I'm not sure yet why.
I'll try using bin/buidout -D (Debug errors.) soon.
Any other suggestions?
I'm used to develop and test from within a single project-directory,
without any staging area, etc. As long as I did use scripts, this worked
very well. But when switching to pkg_resources entry-points, I get
problems: Now I need to ask easy_install (or setup.py develop ...) to
create the "scripts" for me.
python setup.py develop --install-dir . --script-dir .
gives an "error: bad install directory or PYTHONPATH" since the current
directory is not in PYTHONPATH.
I tried other options, too, eg. adding "--editable -b . -N", but with no
success. (This very one works as expected, but creates a
*.egg-link file which will make the next install recurse until dead.)
How can I make easy_install/distribute to generate only the scripts in
the current directory?
A typical setup for me looks like this:
... more stuff ...
And I'm working like this:
# edit my_package/__init__.py
Schönen Gruß - Regards
Dipl.-Informatiker (univ.), CISSP, CSSLP
Spezialist für IT-Sicherheit in komplexen Umgebungen
Monatliche Kolumne: http://www.cissp-gefluester.de/
Goebel Consult mit Mitglied bei http://www.7-it.de
At 09:55 AM 7/7/2010 -0300, Hugo Lopes Tavares wrote:
>Python 2.7 was released in July 3, and until now we don't have
>ez_setup.py working for that. It looks for an egg for each python
>version, and nobody has uploaded that.
>There was a guy here last month with problems to install seutptools in
>his Windows, for a similar reason.
>Is there so much problem to release bdists for Python 2.7?
>And if you come and say to download the tarball and later install, I
>was trying to use virtualenv + Python2.7 and virtualenv uses
>ez_setup.py to create virtual environments.
>Could someone upload the bdists and update ez_setup.py?
The bdists are done now; there was a bit of a problem with a
distutils.command.upload bug introduced here:
(I'm not sure if this bug is also in 2.6 or not, but for 2.7 I worked
around it by having setuptools still use its own upload
command. This is a temporary workaround, of course, until 2.7.1
rolls out I suppose.)