[Distutils] distlib - installer support vs runtime support

Erik Bray erik.m.bray at gmail.com
Mon Mar 11 16:36:17 CET 2013


On Sat, Mar 9, 2013 at 9:33 PM, PJ Eby <pje at telecommunity.com> wrote:
> On Sat, Mar 9, 2013 at 8:14 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> Longer term, something like the import engine PEP may let us implement a
>> cleaner solution.
>
> I've been giving the bootstrapping issue a bit more thought, though,
> and I think there's a way to take the pain out of multi-file
> bootstraps of things like pip and setuptools and whatnot.
>
> Suppose you make a .py file that contains (much like ez_setup.py) a
> list of files to download, along with their checksums.  And suppose
> this .py file basically just has some code that checks a local cache
> directory for those files, adds them to sys.path if they're found,
> downloads them if they're not (validating the checksum), and then
> proceeds to import a specific entry point and run it?

I've been thinking about something like this lately too. A simple
script like your proposed pystart could be used to generate these
files.  I've gone one further and considered a format that includes
dependencies (or at the very least install-time dependencies right in
the .py file itself as a base64 string.  This would work fine at least
for small dependencies--no downloads necessary and you're guaranteed
to get the right version that actually installs the damn package.

For packages using setuptools it's also possible to just include a
dependency as an egg or tar.gz right in your source dist and add
something like "[easy_install]\nfind_links = ." to your setup.cfg and
it'll go.  But I'm not sure that's exactly the use case you're after
here.

Erik


More information about the Distutils-SIG mailing list