[Python-Dev] Status of packaging in 3.3

[Chris McDonough]

On 06/21/2012 12:26 PM, PJ Eby wrote:
> On Thu, Jun 21, 2012 at 11:50 AM, Chris McDonough <chrism at plope.com
> <mailto:chrism at plope.com>> wrote:
>
>     On 06/21/2012 11:37 AM, PJ Eby wrote:
>
>
>         On Jun 21, 2012 11:02 AM, "Zooko Wilcox-O&apos;Hearn"
>         <zooko at zooko.com <mailto:zooko at zooko.com>
>         <mailto:zooko at zooko.com <mailto:zooko at zooko.com>>> wrote:
>          >
>          > Philip J. Eby provisionally approved of one of the patches,
>         except for
>          > some specific requirement that I didn't really understand how
>         to fix
>          > and that now I don't exactly remember:
>          >
>          >
>         http://mail.python.org/__pipermail/distutils-sig/2009-__January/010880.html
>         <http://mail.python.org/pipermail/distutils-sig/2009-January/010880.html>
>          >
>
>         I don't remember either; I just reviewed the patch and
>         discussion, and
>         I'm not finding what the holdup was, exactly.  Looking at it now, it
>         looks to me like a good idea...  oh wait, *now* I remember the
>         problem,
>         or at least, what needs reviewing.
>
>         Basically, the challenge is that it doesn't allow an .egg in a
>         PYTHONPATH directory to take precedence over that *specific*
>         PYTHONPATH
>         directory.
>
>         With the perspective of hindsight, this was purely a transitional
>         concern, since it only *really* mattered for site-packages; anyplace
>         else you could just delete the legacy package if it was a
>         problem.  (And
>         your patch works fine for that case.)
>
>         However, for setuptools as it was when you proposed this, it was a
>         potential backwards-compatibility problem.  My best guess is
>         that I was
>         considering the approach for 0.7...  which never got any serious
>         development time.
>
>         (It may be too late to fix the issue, in more than one sense.
>           Even if
>         the problem ceased to be a problem today, nobody's going to
>         re-evaluate
>         their position on setuptools, especially if their position
>         wasn't even
>         based on a personal experience with the issue.)
>
>
>     A minor backwards incompat here to fix that issue would be
>     appropriate, if only to be able to say "hey, that issue no longer
>     exists" to folks who condemn the entire ecosystem based on that bug.
>       At least, that is, if there will be another release of setuptools.
>       Is that likely?
>
>
> Yes. At the very least, there will be updated development snapshots
> (which are what buildout uses anyway).
>
> (Official releases are in a bit of a weird holding pattern.
> distribute's versioning scheme leads to potential confusion: if I
> release e.g. 0.6.1, then it sounds like it's a lesser version than
> whatever distribute is up to now.  OTOH, releasing a later version
> number than distribute implies that I'm supporting their feature
> enhancements, and I really don't want to add new features to 0.6...  but
> don't have time right now to clean up all the stuff I started in the 0.7
> line either, since I've been *hoping* that the work on packaging would
> make 0.7 unnecessary.  And let's not even get started on the part where
> system-installed copies of distribute can prevent people from
> downloading or installing setuptools in the first place.)

Welp, I don't want to get in the middle of that whole mess.  But maybe 
the distribute folks would be kind enough to do a major version bump in 
their next release; e.g. 1.67 instead of 0.67.  That said, I don't think 
anyone would be confused by overlapping version numbers between the two 
projects.  It's known that they have been diverging for a while.

- C