[Distutils] easy_install - some thoughts

[Paul Moore]

On 7/12/05, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 10:32 PM 7/11/2005 +0100, Paul Moore wrote:
> >2. It would be useful if the -f option worked with a file: URL (or
> >    better still, a simple directory name), to handle local
> >    repositories.
> 
> A good idea, which I've been thinking about.  I'll add it in the next
> release, such that if an argument to -f is not a URL, it gets checked for
> being an existing directory.  If it's a directory, I'll scan the contents
> as if they were links on a webpage.  If it's not an existing directory,
> I'll print a warning (since errors should not pass silently) and proceed.

Agreed. Thanks.

> >3. I still dislike the fact that I can't get a listing of installed
> >    eggs.
> 
> I suggest writing a simple script using pkg_resources.find_distributions(),
> and perhaps adding some documentation and contributing it to setuptools.  :)
> 
> 
> >And uninstalling by deletion isn't good, IMHO.
> 
> So write a pkg_delete script and contribute it, too.

See my earlier message. I will do so.

> I've got no objection to these other tools, they just haven't been my top
> priority and aren't likely to be for a while.  I'd like to focus on the core
> engine/API, in such a way that other people can easily write these
> sorts of management tools around it.

Great. I'll see what I can do to contribute in that area.
 
> >4. --dry-run doesn't work as expected:
[...]
> Sadly, this is about what *I* expect,
[...]
> I've been making the assumption that it's more useful to have a dry run
> that tells you most of what it does before dying, than to have no dry-run
> capability at all.

My reason for using --dry-run was because while I'm happy to do the
build steps in a work area, I don't want to do the install until I see
what will happen (just in case I've got something wrong!) So for me,
dry-run capability is only really crucial for the install step. I'd
actually done all of the previous steps (the build bits) for real in
any case, so the dry run did nothing before failing...

But I see what you mean, it's standard distutils machinery so you
haven't got much freedom to change it, and ultimately when enough
things aren't done, the remaining steps are meaningless anyway.

> >A nice to have feature would be the ability for easy_install to pick
> >apart a bdist_wininst installer and build an egg from it.
> 
> Then I guess it's a good thing I implemented it already.  :)

Cool! Now give back the time machine...

>  Try running  EasyInstall on a win32.exe file, and you'll find that it
> actually does a pretty good job of turning it into an egg.  If you were to run
> "easy_install pysqlite", for example, (assuming you could get past your
> firewall) you'd notice that it finds and downloads the bdist_wininst
> installer for PySQLite, converts it to an egg, and then installs it.  This
> feature is only obscurely referenced in the docs and changelog, so I don't
> really blame you for missing it.  :)

Quick question, is there a "convert but don't install yet" option? So
I get an egg on my PC, but not in site-packages.

> >On a related note, had you thought of having EasyInstall put eggs in
> >a specific subdirectory? Something like site-packages/eggs? As you're
> >using .pth files, this wouldn't be any harder to manage, would it?
> 
> Yes, it would, actually, especially for non-system installs, as Michael
> Hoffman was asking about here recently.  The main reason for putting eggs
> in sys.path directories, however, is to support automatic discovery and
> adding them to sys.path at *runtime*, dynamically.  I also wanted to take
> advantage of certain properties of sys.path, like the fact that Python's
> start script has its directory added to sys.path.  This then makes eggs in
> the script directory easily discoverable.
> 
> In fact, if you set an --install-dir with EasyInstall, and set the
> --always-copy flag, then your installation directory is an "application
> directory".  Scripts and eggs are both copied there, including all eggs
> needed to run the application.  Now you can just ship that directory and it
> can be used anywhere you have Python and setuptools installed.
> 
> Anyway, I think putting eggs in directories on sys.path is a natural
> extension of the sys.path concept, that seems to me to avoid the mental
> overhead of having a separate search path that works differently.
> 
> 
> >I can see a use case for a "combination" egg. One which packages
> >together a group of packages. For example, if I want a standard set
> >of packages installed on all machines, so that users can assume they
> >are present when writing one-off scripts. If I could package
> >*existing* eggs up into a combination site-std.egg
> 
> This is called a "basket" (as in putting all your eggs in one basket!), and
> it's actually already supported,

I told you - give back that time machine! :-)

Seriously, I'm getting more and more impressed...

> Anyway, if you end up with something nice and want to contribute it, that's
> great too.  As with the other tools you've suggested, it's something I
> might get around to eventually, but there are some things I'm dying to get
> working first in the core engine, and I also have a lot of stuff I'd like
> to actually *use* the existing tools for right now.  :)

Will do. I'm much closer to having a feel for where I'd be adding
value and not duplicating effort, so I'll certainly see what I can do.

Thanks for answering my dumb questions.

Paul.