[Python-Dev] packaging location ?

[Paul Moore]

On 13 September 2012 12:32, Tarek Ziadé <tarek at ziade.org> wrote:
> Here's my proposal - actually it's Nick's proposal but I want to make sure
> we're on the same
> page wrt steps, and I think that addresses Antoine concerns
>
> 1. create a new package, called pkglib (or whatever), located at hg
> .python.org as a new project that just strictly contains :
>
>  - the PEP implementations
>  - non controversial features like files parser, pypi index browser etc
>
>   it's doable - since that's what we have done in distutils2. the modules
> that implements those PEPs are standalone

+1. I've seen far too many implementation of code that reads/writes
RECORD files for instance. They are all subtly different and manage to
have incompatible obscure bugs :-(

A reference implementation would be an excellent thing. In the stdlib
by preference, external for older versions is as good as you can get.
The key here is to avoid having packaging tools with any more
dependencies than necessary (because there's a bootstrapping issue
with installing those dependencies...)

>   Let's avoid by all means to put the old distutils command logic there.

+1

>   Let's have a strict process on every new thing we're adding there.

Hmm. Agreed up to a point, but please let's not make it so hard to
change things that are present that people go off and do their own
thing again[1]. OTOH, I agree let's be cautious about adding new
things. Once pkglib goes into the stdlib, that's when things get
strict. Let's leave a bit of flexibility while the details are
thrashed out.

> 2. make pkglib python 2 *and* python 3 compatible - natively, not w/ 2to3

+0

> 3. make distutils2, distribute, pip, bento, etc.  use that and try to share
> as many bits as possible

We can't "make" anyone use pkglib, but if it clearly makes it easier
to support the standards than implementing them yourself, it should
persuade people. And we should certainly advocate supporting PEPs by
using the reference implementation rather than reimplementing it
yourself.

> 4. ask each project to pour in pkglib anything that can be reused by others

+1, although again it'll be down to the projects whether they do
actually contribute. Also this somewhat contradicts the "be strict"
point above, which is why I'm lukewarm on "be strict". Practicality vs
purity - getting contributors/users is more important than insisting
that everything be standardised before it can be implemented.

> when 3.4 comes around, I guess we can decide if pkglib can go in or not.

I'd have an explicit goal to be included in 3.4 (so that people can
imagine an end to the need for pkgutil being a dependency of their
installation tool). But agreed it should not be assumed that this will
happen if it's not ready (that was the mistake with packaging).

> That way, we won't have the usual controversy about distutils' command
> machinery. People will use whatever tool
> and hopefully this tool will be based on pkgutil

+1. It also means that people will have a much greater incentive to
support the new standards, because it should simply be a case of
calling the pkglib implementation.

Paul.