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, including dependencies. 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.
Yep.
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. Carl