[Distutils] EasyInstall: suggested usage patterns
ianb at colorstudy.com
Wed Jun 15 20:17:29 CEST 2005
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:
* I am developing an application. I don't have a distutil script for
* 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...
* 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.
* I'd like to distribute some data that doesn't have much (or maybe any)
(a bunch of templates and images), or something like that. Can I
facilitate that with easy_install?
* 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
More information about the Distutils-SIG