[Distutils] What is the official position on distutils?

[Nick Coghlan]

On 5 September 2016 at 00:27, Sylvain Corlay <sylvain.corlay at gmail.com> wrote:
> Hi Steve,
>
> - I posted an on setuptools github
> https://github.com/pypa/setuptools/issues/771 to ask the setuptools folks
> (and especially Jason) whether they would want such a feature.
>
> I still find it baffling that the preferred way to add distutils features
> would be to monkey-patch it via setuptools first and then to add it into
> distutils later, while my proposed approach was to add it to distutils and
> monkey patch for earlier versions of python.

Imagine a world where distutils wasn't rife with global state, and
hence setuptools didn't need to monkeypatch it, and the approach seems
more logical (e.g. this is roughly the way I've worked for larger
contextlib changes - the ContextStack precursor to ExitStack only
exists in contextlib2, since I didn't push that API to the stdlib
until I was happy with both the design and the name).

> - Regarding the policy that you just nominated, does this apply to things
> that have been in pip for a long time? In the initial email that triggered
> this discussion, it was also question of adding the
> `pip.location.distutils_scheme` convenience function to distutils itself. Cf
> https://bugs.python.org/issue26955 and pip's implementation at
> https://github.com/pypa/pip/blob/281eb61b09d87765d7c2b92f6982b3fe76ccb0af/pip/locations.py#L124
>
> Indeed, the problem with certain distutils commands like `install_headers`
> is that the only way to retrieve the directory where things were installed
> is to instantiate a `distutils.dist.Distribution`
> object, which is not trivial to do. pip's distutils_scheme convenience
> function does it. This function is *about* distutils, and IMO should really
> be *in* distutils.

Should it be in distutils, or should it be in the version independent
"packaging" helper library that pip uses?

It's important to note that one of our key goals in PyPA is to get to
a point where the API of a developer's publishing toolchain of choice
only depends on the *version of the publishing tools* they're using,
and not on the specific version of Python (as long as they're using a
supported version). Encouraging the expansion and increased use of the
distutils API runs counter to that goal in most cases (since it
encourages writing publication and distribution code that will only
work with newer versions of Python), but may sometimes make sense if
it's info that really is CPython centric, or if it's a feature
primarily aimed at tightly controlled environments that can
aggressively drop support for older versions.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia