[Distutils] pip vs easy_install vs distutils2
carl at oddbird.net
Mon May 31 16:43:42 CEST 2010
Tarek Ziadé wrote:
> I won't speak for others, but on my side, I don't underestimate the
> amount of work involved in an installer (heck, if I was scared by the
> amount of work in packaging, I'd quit 2 years ago ;)), but rather
> trying to figure out what is the path for a better packaging
> ecosystem. (it's a bit of a wicked problem)
Indeed! (If anyone's put in enough time in packaging in the last couple
years to make writing a new installer from scratch seem possible; it
would be you. I hope we can find a solution that allows that energy to
be put into something more productive, however!)
> A - If distutils2 doesn't include an installer, a fresh Python install
> will not be fully functional. I don't think it's the best option.
> Python should provide an installer/uninstaller that is compatible with
> the latest standards distutils2 provides. I don't want to release a
> software that will have to rely on a third party installer which don't
> exists yet : there's no clear plan to support the new standards yet in
> pip or in any other project afaik.
I agree that it makes sense for there to be an installer packaged with
distutils2 that supports all the features of the metadata standard,
As far as "clear plan," what sort of plan are you looking for? The
direction of pip mainline is up to Ian, of course, but I personally plan
to do what I can towards a branch of pip that works with the new
standards by the time distutils2 is released with a Python release.
Given that pip will largely sit "atop" distutils2, I don't think it
makes sense to start on the work in pip until distutils2 has stabilized.
> B - adding within distutils2 an installer like pip (with the support
> of new standards) at a given version doesn't mean you can't develop
> the next version and release it as a third party package, so people
> can upgrade their installer and get the bleeding edge thing.
> This is doable as long as the installer is configurable.
> Now about the backward compatibility issues:
> - as discussed with Ian, we are going to add backward compatibility in
> pkgutil, so we
> can read old egg-info formats. IOW, it deprecates the usage of
> pkg_resources in favor of an unified API.
Great! I must have missed the end of that discussion in IRC.
> - if the installer part of distutils2 includes backward compatibility,
> it's ok I guess, as long as it's isolated to that part.
If the pkgutil API is integrated and backwards-compatible, the remaining
backwards-compatibility considerations would be:
1) Package installation. This shouldn't be too difficult ("setup.py
install"), though if we want to be able to install old packages using
the new PEP 376 installation format, that would involve some work.
2) Package-finding. I don't know if there's been discussion yet about
whether the new distutils2 world will continue the same liberal
link-searching algorithms that easy_install pioneered, or whether there
will be a move towards something more structured.
> So, I am still proposing to merge both projects and to have two kinds
> of releases:
> - distutils2 + pip included (maybe a renamed script)
> - pip, alone.
This sounds good to me. I don't really care what the included one is
called, though to me renaming sounds mostly like asking for confusion.
More information about the Distutils-SIG