[Python-Dev] Internal documentation for egg formats now available

[Phillip J. Eby]

At 09:54 PM 4/27/2006 +0200, M.-A. Lemburg wrote:
>Note that I was talking about the .pth file being
>writable, not the directory.

Please stop this vague, handwaving FUD.  You have yet to explain how this 
situation is supposed to arise.  Is there some platform on which files with 
a .pth extension are automatically writable by users *when .py files are 
not also*?

If not, then you are talking out of your... um, hat.  If files are writable 
by other users by default, then .py files are too.  Once again: *no new 
vector*.


>Even if they are not
>writable by non-admins, the .pth files can point
>to directories which are.

Uh huh.  And how does that happen, exactly?  Um, the user puts them 
there?  What is your point, exactly?  That people can do things insecurely 
if they're allowed near a computer?


>Here's a HOWTO to optimize startup time, without loosing
>convenience:

I meant, a HOWTO for setuptools users who care about this, although at the 
moment I have heard only from one -- and you're not, AFAIK, actually a 
setuptools user.



>No, I'm talking about a format which has the same if not
>more benefits as what you're trying to achieve with the
>.egg file approach, but without all the magic and hacks.
>
>It's not like this wouldn't be possible to achieve.

That may or may not be true.  Perhaps if you had participated in the 
original call to the distutils-sig for developing such a format (back in 
December 2004), perhaps the design would've been more to your liking.

Oh wait...  you did:

http://mail.python.org/pipermail/distutils-sig/2004-December/004351.html

And if you replace 'syspathtools.use()' in that email, with 
'pkg_resources.require()', then it describes *exactly how setuptools 
works  with .egg directories today*.

Apparently, you hadn't yet thought of any the objections that you are now 
raising to *the very scheme that you yourself proposed*, until somebody 
else took the trouble to actually implement it.

And now you want to say that I never listen to or implement your 
proposals?  Please.  Your email is the first documentation on record of how 
this system works!


>Not really.

Then I won't bother adding it, since nobody else asked for it.  But don't 
ever say that I didn't offer you a real solution to the behavior you 
complained about.

Meanwhile, I will take your choice as prima facie evidence that the things 
you are griping about have no real impact on you, and you are simply trying 
to make other people conform to your views of how things "should" be, 
rather than being interested in solving actual problems.

It also makes it clear that your opinion about setuptools default 
installation behavior isn't relevant to any future Python-Dev discussion 
about setuptools' inclusion in the standard library, because it's:

1. Obviously not a real problem for you (else you'd accept the offer of a 
feature that would permanently solve it for you)

2. Not something that anybody else has complained about since I made --root 
automatically activate distutils compatibility

In short, the credibility of your whining about this point and my supposed 
failure to accomodate you is now thoroughly debunked.  I added an option to 
enable this behavior, I made other options enable the behavior where it 
could be reasonably assumed valid, and I offered you an option you could 
use to globally disable it for *any* package using setuptools, so that it 
would never affect you again.

(And all of this... to disable the behavior that implements a scheme that 
you yourself proposed as the best way to do this sort of thing!)