[Python-Dev] Internal documentation for egg formats now available (original) (raw)

Phillip J. Eby pje at telecommunity.com
Fri Apr 28 00:04:48 CEST 2006

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!)

More information about the Python-Dev mailing list