On Fri, 23 Mar 2018 at 19:35:55 +0000, Simon McVittie wrote:
> When a small subset of distutils moved back, I assume that the
> intention was to un-break the relatively common(?) case of users of
> distutils.version that do not need the rest of the module, such as
> the gdbus-codegen tool in libglib2.0-dev-bin. However, it isn't clear
> whether the Python maintainers consider this to be a workaround to keep
> those packages working in the short term (in which case they need to
> pick up a new dependency on python3-distutils for the longer term), or
> whether distutils.version is going to remain part of the API of -stdlib
> in the long term (in which case packages like libglib2.0-dev-bin should
> not depend on the full -distutils package because that would negate the
> benefit of splitting it out).
Some notes from IRC:
<smcv> doko: I see you moved distutils.version back to
libpython3.6-stdlib. is that temporary/transient, or is your
intention that it goes back to being part of the ABI guaranteed
by the python3 package?
<smcv> doko: (in other words, can packages like libglib2.0-dev-bin that
only need distutils.version but not e.g. distutils.sysconf drop
their dependency on python3-distutils again?)
<doko> smcv: yes, .version should stay there. I wouldn't like .sysconfig
there, because python3 has a proper sysconfig module, and glib2.0
seems to prefer that one over .sysconfig
(I think doko mentioning sysconfig was a reference to its use in
the AM_PATH_PYTHON macro, which does indeed prefer sysconfig over
distutils.sysconfig - but libglib2.0-dev-bin also legitimately has a
runtime dependency on a small part of distutils, not just a build-time
dependency, because gdbus-codegen uses distutils.version.LooseVersion to
sort version numbers in a way that is predictable cross-platform.)
Also:
<bunk> What is the plan for finding all runtime dependencies on
python3-distutils?
<smcv> bunk: good question. codesearch for "(from|import) *distutils"
is the best I can think of?
and some subsequent discussion of how that codesearch will produce a
very large number of false positives (for example in AM_PATH_PYTHON),
which should be eliminated before filing bugs.
On Fri, 23 Mar 2018 at 20:30:17 +0000, Jeremy Stanley wrote:
> This may also serve to help narrow down (via reverse dependency) the
> list of packages which will trigger violent reactions when mixed in
> the same context with pip 10 invocations, per
> https://github.com/pypa/pip/issues/4805 .
Am I right in saying that there is a distutils limitation that means
the Python equivalent of "make uninstall" isn't reliable for packages
installed with distutils, and as a result, upstream developers want to
deprecate distutils?
While deprecating libraries that have unfixable problems is a reasonable
goal, I'm reasonably sure that installing a library with apt/dpkg and
uninstalling it with "sudo pip uninstall" is not something we (should)
aim to support? Or am I misunderstanding?
(Packages that were merely built with distutils won't normally depend
on distutils in any case, only build-depend.)
I thought the upstream Python maintainers strongly objected to the idea
of us installing something that claims to be Python but doesn't have
the complete Python standard library (in the interests of having Python
mean something predictable between OSs), but perhaps that information is
out of date and doesn't apply to distutils any more?
smcv
