On Thu, Jul 23, 2009 at 5:43 AM, <david.l...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com