TL;DR: OK to archive this mailing list? Reply by Aug 30th.
Below: Context, Proposal, Reasoning, and timeline.
For multiple years now, we've been advising users to use setuptools and
to move away from using distutils. There has been a long standing
plan [^1] to vendor distutils into setuptools to allow it to evolve
independently of the Python standard library and to allow for removal of
distutils from the Python standard library.
Recently, setuptools adopted the distutils [^2] which, as far as I can
tell, starts the long process of removing distutils from the Python
standard library. PEP 517 [^3] also removed the special status of
distutils/setuptools as the only pipeline that can be used for
generating distributions for Python projects.
For some time now, "distutils" has not been a "primary" tool in the
broader Python Packaging ecosystem, with setuptools being an overall
superior tool that also has a good interoperability story with the other
Python packaging tooling. This is acknowledged in the description of
this mailing list as:
> Now, it's better described as the "packaging interoperability SIG",
> where issues that cut across different parts of the Python packaging
> ecosystem get discussed and resolved.
However, this mailing list is no longer serving this stated role either,
with the Packaging category on discuss.python.org becoming the primary
location for packaging tool interoperability discussions.
Over the last year, the Packaging category on discuss.python.org had 841
active topics, with only 40 topics with 3 or fewer responses. [^5]
In the last 100 days, the Packaging category on discuss.python.org has
had 91 active topics. More than 10 PEPs have been discussed in the
Packaging category on discuss.python.org in the last 100 days.
Over the last year, distutils-sig had ~109 active threads, with
(based on a quick skim) most having 3 or fewer responses/posters. [^4]
In the last 100 days, distutils-sig has had 32 active threads (at least
7 of these have the same subject as another thread with Re:/Fwd: added).
There has been only 1 PEP-related feedback discussion on distutils-sig
in the last year. Most of the other threads are user support requests or
I suggest that, one month from now, we stop posting to this list
(distutils-sig(a)python.org) and archive it.
I think we do not use this mailing list for its dedicated purpose, and
it does not serve any secondary function that isn't better served by a
different communication channel already.
(1) this mailing list is no longer the primary location for
(2) we have better channels for user support requests (such as
issue trackers of various projects, packaging-problems etc.)
(3) we have other channels for making announcements (such as the
pypi-announce mailing list, the PyPA twitter account,
Here's what I suggest, and what I will carry out if there is no
In one month, on August 30th, I would verify that no one has argued here
for why this mailing list should not be closed/archived.
Or, even if a few people have objected to closing the list, I would
check for rough consensus, especially of people who are doing SOMETHING
productive having to do with Python Packaging (such as maintainers of
Python packages, maintainers of Python Packaging tooling, folks running
key infrastructure, etc.).
Then, I would request the list administrators to post a final message
to this list (marking its close and suggesting that people use
discuss.python.org instead) and, to archive this mailing list. This
would leave archives available at their current URLs, so links, browsing
and search would work.
And finally, I would look through relevant documentation within PyPA
repositories to see what needs updating (READMEs and so on pointing to
the old list), and submit pull requests.
I appreciate the work folks here have done to carry forward Python
packaging over the past 21 years of this mailing list. I don't mean to
diminish that or to insult anyone here. I want to help us out, and I
think closing this list will help focus our energy better. But I am
open to hearing that I am wrong.
The ".taskslab11419" section of your version name doesn't meet the
requirements for version numbers described in
the only non-numeric text elements permitted are "a" (alpha releases), "b"
(beta releases), "c" (release candidates), "dev" (dev releases), and "post"
The simplest resolution would be to drop the ".taskslab11419" section, and
just make the version 0.2.0 instead. Alternatively, if keeping the number
is important, you could make a dev release (0.2.0.dev11419), or use a 4
segment version number (0.2.0.11419).
On Tue, 27 Apr 2021 at 14:01, Bianca Reyes <biancamoniquereyes(a)gmail.com>
> Hi Nick and Donald,
> I’m emailing you because I can’t seem to resolve an issue with my project
> wherein I try to install using pip command and it returns:
> WARNING: Built wheel for SomeProject is invalid: Metadata 1.2 mandates PEP 440 version, but '0.2.0.taskslab11419' is not
> Failed to build SomeProject
> I’ve read your documentation with PEP 440 version but my version name
> *0.2.0.taskslab11419* does not seem to be invalid based on your
> documentation. Can you guys help me out here? I’ve been trying to fix this
> for almost a week now but to no avail.
> Btw, I’m using python3.8 and pip 21.1 version.
> Hoping to hear from you soon.
> Thank you and cheers,
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam…> Virus-free.
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
I'm the author of python-libusb1, a pure-python ctypes wrapper for
Until recently, I had been purely relying on OS-linker-provided libusb1
(distro-installed on GNU/Linux and *BSD, fink/macports/... on OSX, ...).
Then, I've been requested to bundle the libusb1 dll on windows (x86 and
x86_64 wheels) because otherwise distributions seems exceedingly
painful for applications using my module. With some extra code to
setup.py to fetch, unzip and copy the dlls, plus a now even more
multi-stage distribution process (sdist, both windows wheels, in
addition to the existing sign and twine steps), and it ipso facto works.
Now, I'm asked to add pyinstaller compatibility, as it on its own
overlooks the dll. Which makes me feel that I am maybe not using the
best possible way to bundle these.
From my reading of distutils and setuptools, my understanding is that a
package is that non-pure-python packages contain:
- stuff they built themselves (build_ext & friends)
- third-party libraries that the stuff they built themselves is linked
Having nothing to build, I cannot seem to reach the library inclusion
What is the recommended way of bundling a third-party-built
arch-dependent library in an otherwise pure-python package ?
GPG fingerprint 983A E8B7 3B91 1598 7A92 3845 CAC9 3691 4257 B0C1
I have a project with a fairly involved build process where we generate
C++ via a python-clang-based code analyser, generates Python bindings
for the resulting C++ API with SWIG, and finally compile and link to
create various .so's and .py files.
I'd like to package things up with a setup.py script, but from what i
have read, it looks like distutils expects to compile, link and run
swig itself, using distutils.core.setup()'s ext_modules arg?
Is there a way to write setup.py so that it instead runs an external
command (e.g. 'cd foo && make all') when it is asked to build?
Thanks for any help,