[Python-Dev] Status of packaging in 3.3

[PJ Eby]

On Thu, Jun 21, 2012 at 11:50 AM, Chris McDonough <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>> 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.)

Anyway, changing this in a snapshot release shouldn't be a big concern; the
main user of snapshots is buildout, and buildout doesn't use .pth files
anyway, it just writes scripts that do sys.path manipulation.  (A better
approach, for everything except having stuff importable from the standard
interpreter.)

Of course, the flip side is that it means there won't be many people
testing the fix.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120621/768f50f0/attachment.html>