[Distutils] EasyInstall: suggested usage patterns

[Ian Bicking]

Hi -- I'm getting ready to go out of town, so I haven't been able to
track everything that's gone on in 0.4 (or 0.5 now?), and I might not be
able to follow up on this conversation very thoroughly, but anyway...

I feel like we need several suggested ways to use easy_install and eggs,
given different cases.  This is probably a documentation task; I'm more
interested in how I *should* use this, rather than how I *can*.  I guess
that's the same as best practices.  In turn I'd like to echo these best
practices in any documentation or examples that use easy_install/eggs.

Anyway, here's some cases:

Development

* I am developing an application.  I don't have a distutil script for
the application.

* I am simultaneously developing distutils-based libraries.  I want to
edit these during my development process.

* I also have some distutils libraries that I'm not developing, but I
need to install.

* I also have some libraries laying around that I already installed
(before easy_install existed).  And some that are from OS packages.

* I have other Python stuff on my computer that I don't want to mess up
because of my ongoing development.

So, given this, what commands do I run?  Where do I put files?  What if
I don't have permission to put files in global locations
(site-packages)?  How do I clean up after myself later?


Later, this becomes...

Deployment

* I have developed a web application.  Maybe it also doesn't have a
distutils script...?  It could, though currently I don't develop one for
my web applications.  Also, I sometimes make hot fixes, especially when
the application is deployed but not yet live.

* How and where should libraries be installed?  How should application
dependencies be expressed?

* Some libraries are internal, and so aren't available from a public
location.  Maybe on the web with HTTP auth, though I'm more inclined to
simply keep them in a branch in the private repository.  Or fetch over scp.

* Should I change my require()s to use a specific version of the
libraries, so that I don't accidentally upgrade (/break) the application
when a later application is installed?  How do I manage that process?

* Later a library might be broken and I need to fix it.  Is there
anything I should do on installation so I can later track who uses what
library?  Also so I can collect unused versions of libraries.


Non-code

* I'd like to distribute some data that doesn't have much (or maybe any)
code.  This might be a Javascript library, or a skin for the application
(a bunch of templates and images), or something like that.  Can I
facilitate that with easy_install?


Enabling plugins

* I have library A, and library B.  Library B optionally provides a
"plugin" to library A, but both are usable in isolation.  Library B
needs to inject stuff into library A -- i.e., at runtime some code in
library B enhances library A.  How do I make this work?  How do I make
library A aware of library B?


Other People's Code

* Someone wrote some code I'd like to use.  But it's poorly packaged --
maybe no setup.py, or maybe a bad one.  For instance, I've decided that
zpt.sf.net's setup.py is just broken -- you can't use extra_path, no
package, and provide an __init__.py all at once.  I'd like to write my
own setup.py, but use that package.  And it's on SF, so I'd like to use
easy_install to download the package.


Those are some of the things I'd like to do now -- easy_install doesn't
have to magically make all of them work wonderfully; if I have to do
things by hand, keep separate records, write custom code, or whatever,
that's fine; I just want to know what I should be doing right now for
each of these cases.  Also, I'm interested in conventions we can define
so that we all start doing the same thing.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org