[Distutils] Distribute sprint #1 wrapup

kiorky kiorky at cryptelium.net
Sat Oct 24 19:13:06 CEST 2009

Whow sorry, Ignore my precedent mail, i missed the end of that email., i do not
know why. Blame my eyes or thunderbird :/

> PEP 376 comes with a set of tools that will allow you to
> install/uninstall distributions
> in an arbitrary site-packages folder, and play with them. So it
> basically makes almost no
> differences for tools like zc.buildout-the-package-manager that is
> tweaking sys.path in
> the generated scripts.
Great (really) :) Entry points are working as well on those non standard places
also, aren't they?

> I guess the simplest way will be to make the "eggs" directory a
> regular site-package
> like folder.  It will even simplify the scripts because you will not
> have to add one entry per eggs
> there as it is today.
I don't think it is a really good idea because you will not have isolation at
project level. If you have A, B, C in this alternative site-packages, it would
mean that A, B, and C are importable. But when i install something with "eggs=A
C", i want that my pythonpath contains A and C but no B.I think the buildout way
to do that actually is not that bad :)

> What could be awesome is to see a branch of zc.buildout built against
> distribute 0.7
Indeed. I ll rework the minitage recipes also to use pip and prepare work for
distribute on a branch as soon a possible, i hope next we.

> when it starts to be usable, to experiment this.
> zc.buildout is a package manager, so it makes it one of the target use
> case for PEP 376
> and other changes we will provide in distribute.
How about trying to make a mirror of pypi packages rebuilt in the distribute
format. That will prevent the overhead for users to contact the maintainer in
case or breakage, to the maintainer to have to repackage its already packaged
things, and also for the user to have problems installing 'foo' even it is a
very simple package that we could just provide a rebuilt version to him.
I think about that mainly for distributions packaged only as eggs (in the actual
format). We could maybe extract this list of packages with no sdist (not that
much i think and the only one i know is plomino) and repackage them. That's very
low priority, but it can be useful and one more other step which will make the
transition as transparent as possible.

So mainly because i did not find time yet to test, and i will, my only concern
WHICH MAY BE UNFOUNDED is on namespaces conflicts between setuptools and
distribute. For me, the first one loaded module wins. And, it's low priority any
way i think as a patch may by easy to do.

Just one thing to borrow from the precedent mail would be to make one sentence
on the PEP to write in rock that we can make installation elsewhere that in
standard place for both python code & metadata.

GPG Key FingerPrint: 0x1A1194B7681112AF

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20091024/74d5140e/attachment.pgp>

More information about the Distutils-SIG mailing list