[Distutils] pip vs easy_install vs distutils2

[Jason Baker]

On Fri, May 28, 2010 at 6:13 PM, Tarek Ziadé <ziade.tarek at gmail.com> wrote:

> Hello,
>
> Distutils2 is going to be added back in Python (hopefully in 3.2) and
> without an install script, it's pretty useless as-is.
>
> We've discussed during the summit at Pycon to create some kind of
> bootstrap script in Python, to allow people to
> set up an installer of their choice, but I think it's a bad idea.
>
> = summary of the summit proposal =
>
> IIRC:
>
> - an "install" script is added in the scripts, for people to install
> distributions in Python. Could be called "pyinstall" for example.
>
> - when first used, it would ask the user to choose a third-party
> installer (like Pip). Then it would download it and
>  install it with a simple "python setup.py install"
>
> - from there, the install script would be linked to that installer.
>
> If I recall it correctly, this feature was proposed to be able to have
> a "modern" installer in Python without
> including it in the standard library. (so it can have its own shorter
> release cycles). The bootstrap story
> would just make it easier for people to get an installer, without
> having to do extra manual steps.
>
> The problem I have with this approach is that we need to manage
> somewhere at PyPI a list of potential installers,
> and maybe deal with upgrades and replacements. Plus, I am not sure
> that a user will really understand what to
> do when he's asked to chose an installer. Sounds like something we
> should only ask to power users, and
> people that know what they are doing with p7g. So a bootstrap script
> is useless for them.
>
> = alternative proposal =
>
> Let's add that script but powered by Distutils2. It could be Pip if
> people from this project think it's a good idea and want to merge, or
> an easy_install derivation, or a new script from scratch.
>
> IOW: you get an installer for free in the stdlib without having to think.
>
> Now for the problem of the release cycle (e.g. once in the standard
> library it has to wait 18 months for a new version),
> I propose that Distutils2 allow the usage of a third party installer
> through configuration. IOW, Distutils2 would ship with an installer,
> but could use through a simple change in distutils.cfg, another one
> installed by a third party project that is more recent.
>
> For this to work, we can define an installer standard interface ala
> wsgi. Basically, we state that an installer has to implement a simple
> function that takes a name of a project to install, and an optional
> version predicate:
>
>    def install(name, version=None):   # if version is None, it means
> the latest one.
>       ...
>
> This needs more work, uninstall is missing in that description, and
> what about the script options, etc. but you get the idea: make sure
> people can use the installer of their choice, if it turns out that the
> one provided by Distutils2 is not good enough anymore for any reason.
>
> Any opinion ?
>

One possible route would be to have distutils2 have an API that's similar in
concept to Apache Ivy[1] (but being pythonic, rather than requiring XML and
being Java oriented :-) ).  This way, people can build tools like pip and
easy_install with more standard behavior to make installing packages
easier.  That said, you wouldn't really *need* those packages.  The only
thing that you would really need is the Python interpreter and distutils2.
This would make it fairly easy to customize the build and installation
process as well (especially for tools like buildout or envbuilder).

[1] http://ant.apache.org/ivy/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100601/ca7b3bb0/attachment.html>