[Python-3000] Proposal: No more standard library additions

Ron Adam rrr at ronadam.com
Sat Oct 14 21:30:15 CEST 2006


Phillip J. Eby wrote:
> At 12:00 PM 10/14/2006 +0200, "Giovanni Bajo" <rasky at develer.com> wrote:
>> Ivan Krsti? wrote:
>>> Talin wrote:
>>> That'd be nice. And on that note, for the love of confused masses
>>> everywhere, can we please change the name of easy_install to something
>>> Python-specific, such as 'egg' or 'py_install'?
>> +1. I think at some point I heard mentioned the name 'nest' for a program that
>> manages eggs. I am not sure whether Philip's wanted it to have the features of
>> easy_install or not, though.
> 
> Yes.  "nest" will be an overall command similar to "yum" or other package 
> managers of its ilk, with subcommands like "nest install" that will work 
> like easy_install.
> 
> However, "nest install" will not have easy_install's arcane option set, nor 
> will it be able to do all the things easy_install does.  Instead, things 
> like "easy_install -eb. packagename" (fetch and unpack a project's sources 
> to a subdirectory) will become something like "nest source packagename", so 
> that there are separate commands for different use cases instead of one 
> arcane super-command.
> 
> Also, instead of using options to specify installation locations, it's 
> likely that nest will have, well, "nests", which are configured locations 
> for installing packages, scripts, source, headers, etc.  So at most you 
> would specify what nest to use when invoking a command.  But there will 
> also be a "nest use nestname" command that will invoke a subshell in which 
> the given nest will be the default.
> 
> But before anybody asks, I have no clue when I'll even be able to start on 
> writing nest, let alone finishing it.  I'm still shoring up leaks in the 
> abstractions of setuptools as it sits; for example, last night an OSAF 
> developer discovered that the 'ext_package' option to setup() (which I'd 
> forgotten even existed) didn't work right with setuptools' "test" 
> feature.  Distutils is *very* very big.  :(  If I'd known what I was 
> getting into before I started, I'm not sure I would've done it.
> 
> Distutils itself is in sore need of a 3K-ing.


Will "nest" (or what ever it's called) be a single module to handle everything? 
or will it be a front-end to distutils?

It would probably be a *lot* easier to write and maintain if it were a simple 
front end to disutils and is used to inspect eggs (via lists) and having 
disutils do the work of installing or un-installing them.

Ideally each egg would know what it is and where it belongs (*) and so it could 
then only be a matter of getting the install info from the eggs:

   description
   author/owner/home-page
   license
   www install-from location  (to use if egg is not here)
   install-to location
   external dependencies (other eggs (or software) needed)

... and then sorting them accordingly... installed, not installed, pythonlib, 
third party package, etc.

If it were a gui app, then I envision having items highlighted in green if all 
the external dependencies (other eggs) are already installed and red if they 
aren't.  Things like that could make life easier for many people I think.


(*) It's install location might be either a default, relative directory, or an 
environment variable name.

_Ron



More information about the Python-3000 mailing list