Your message dated Sat, 22 Mar 2025 23:39:41 +0000
with message-id <[email protected]>
and subject line Re: python3-distutils: Please describe road
map/recommendations for users of distutils
has caused the Debian Bug report #893924,
regarding python3-distutils: Please describe road map/recommendations for users
of distutils
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
893924: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893924
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: python3-distutils
Version: 3.6.5~rc1-2
Severity: wishlist
X-Debbugs-Cc: [email protected]
I'm confused about the current status of distutils, and what should be
done by packages that depend on it to be as future-proof as possible. I
don't think I'm the only one confused by this, so it would be very
helpful if a maintainer could clarify what the intention is so that
other maintainers can do the right things.
When structural changes like this are needed, I think it would
be useful for them to be represented by a bug (perhaps of the form
"libpython3.6-stdlib: should not contain distutils" or something similar)
that gives the reasons for the structural change and describes the
action that should be taken by maintainers of dependent packages. This
bug could be referenced in the changelog and would be an obvious central
coordination point for whatever changes are needed, including follow-ups
if unforeseen fallout means the plan has to change. The release team
would probably also appreciate it being treated as a transition so that
they can plan around it.
Since that didn't happen in this case, I'm opening this bug in the hope
that it can fulfil a similar role.
So far, the sequence of events goes something like this:
* 13 December 2017: distutils moves from -stdlib into its own package
* 20 March 2018: -stdlib stops depending on distutils, packages start
to fail to build from source
* 22-23 March 2018: A small subset of distutils (__init__.py and version.py)
moves back to -stdlib
I assume there is a reason (size on disk? dependencies? update
frequency?) why most of distutils shouldn't be in -stdlib, but in the
absence of a reference in the changelog, I can only guess at why that is.
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).
I'm aware that structural changes that break dependencies are sometimes
necessary in pursuit of a goal (I've done them myself, most recently
moving glib-compile-resources to libglib2.0-dev-bin for #885019), but
when making them, having a plan visible to everyone is beneficial.
Please could you clarify the situation?
Related bug reports include:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893755
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893847
Thanks,
smcv
--- End Message ---
--- Begin Message ---
On Sat, 22 Mar 2025 at 19:28:12 +0100, Alexandre Detiste wrote:
Can this be closed now ?
Yes, my request on #893924 has been made irrelevant by changes that
subsequently happened.
My understanding of the current situation is that distutils is no longer
in the Python standard library, either upstream or in Debian. Packages
that require "import distutils" or "from distutils import..." can still
get that in the short term by (build-)depending on python3-setuptools,
but that is a deprecated thing to do and ideally they should do
something else, such as:
- replacing distutils.version.LooseVersion with python3-looseversion
or similar;
- replacing distutils.version with packaging.version from
python3-packaging;
- replacing distutils.sysconfig with sysconfig from the Python standard
library;
- replacing distutils with direct uses of python3-setuptools, or another
PEP 517 build backend like flit, python3-hatchling or python3-mesonpy
smcv
--- End Message ---
