[Distutils] Q about best practices now (or near future)

[Vinay Sajip]

>
>If the long-term plan is to bless setuptools then go for the bundling, but if that decision has not been made yet then bundling may be premature if the bundling of pip with Python moves forward.
>


Well, Nick has said that he thinks that "distlib is the future" (or, I assume, something like it - something that is based on PEPs and standardisation rather than a de facto implementation which a sizeable minority have problems with, though it's pragmatically acceptable for the majority).

If distlib or something like it (standards-based) is to be the future, we have to be very careful. As I've said to Nick in an off-list mail, that sort of future is only going to fly if sufficient safeguards are in place such that we don't have to have compatibility shims for setuptools, pkg_resources and pip Python packages/APIs. Based on the actual work I did to replace pkg_resources with distlib in pip, it's not a thing I really want to do more of (or that anyone else should have to do). So, ISTM that pkg_resources and setuptools would need to be subsumed into pip so that they weren't externally visible - perhaps they would move to the pip.vendor package. Otherwise, we might was well accept pkg_resources and setuptools into the stdlib - no matter how many ifs and buts we put in the fine print, that's what we'd essentially have - with apologies to Robert Frost and to borrow from what Brett said, "the lazy road is  the one most travelled, and that
 makes all the difference". Plus, there would need to be sufficient health warnings to indicate to people tempted to use these subsumed APIs or any pip API that they would be completely on their own as regards future-proofing. In my view this can't just be left up to the pip maintainers to decide on - it needs to be a condition set by python-dev, to apply if pip is shipped with Python. Otherwise, backward compatibility will tie our hands for ever (or at least, a very long time).

Regards,

Vinay Sajip