[Python-Dev] Update to Python Documentation Website Request

[Jesse Noller]

On Thu, Jul 23, 2009 at 5:43 AM, <david.lyon at preisshare.net> wrote:
>
>> Raising it without at least glancing at the list archives which hold
>> copious amounts of virtual text on that topic is somewhat inappropriate
>> though :)
>
> Well I have consulted every available expert on the distutils list to the
> point where I feel 'up' with the issues at hand.
>
> They're great people.. And as helpful as they possibly can be..
>
> But surely Python isn't only about archives and age old problems.
>
> Sure they might be there.. So lets get in and fix them..
>
> Which is totally what i'm attempting to do at the moment even if packaging
> isnt perceived as being the most interesting part of python develepment
> going on today.
>
> Inapropriate or not, i want to donate my time to it.. Because i think we
> need 'fresh' thinking - not archive regurgitation.
>
>
> David

Then why not include pip, easy_install, and this bash script I use to
install packages into core? The more the merrier, right?

Answer: None of these are standards, and as nick points out, there's
issues with sysadmins, security, and other things. Not to mention
they're fundamentally not part of the language.

At the language summit, this was hashed out quite a bit. I think most
everyone agreed that tools like easy_install, pip, virtualenv,
zc.buildout, etc simply do not belong in core python. The
"installation" landscape varies from platform to platform, it can run
full in the face of people who just want to use apt or yum, etc.

What *does* belong in core (distutils) however, and is something Tarek
has been working on, are APIs/Hooks/standards for tools like the ones
I've mentioned, and yours, to be able to do their job better, cleaner
and easier. Standards on metadata, uninstall hooks, etc are what the
stdlib should provide, not applications and tools built on top of
those things.

IMHO, the only "binary" python-core itself should "ship" is the python
binary itself (and pydoc, maybe :-)) - everything else should be built
with the idea of making integration with internals easier and
standard. That way OS package maintainers can hook into these APIs
(because they don't want to use something "non standard" to them),
people such as yourself can build GUI apps for downloading and
managing things, etc.

I know you want to help, and I don't think anyone is discouraging that
- but I think instead of solely focusing on your application is a
mistake. The bulk of the effort should be spent helping Tarek and
others "fix" distutils and spraying down bikeshedders so progress can
be made.

jesse