Distutils-SIG February 2021

distutils-sig@python.org

4 participants
5 discussions

Archive this list & redirect conversation elsewhere?
by Pradyun Gedam 09 May '21

09 May '21

TL;DR: OK to archive this mailing list? Reply by Aug 30th. Below: Context, Proposal, Reasoning, and timeline. *Context*: 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 announcements. *Proposal*: I suggest that, one month from now, we stop posting to this list (distutils-sig(a)python.org) and archive it. *Reasoning*: 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 interoperability discussions (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, discuss.python.org etc.) *Timeline*: Here's what I suggest, and what I will carry out if there is no objection. 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. Realizing-that-distutils-sig-is-older-than-me-ly, Pradyun Gedam [^1]: https://www.pypa.io/en/latest/roadmap/#vendor-distutils-into-setuptools [^2]: https://github.com/pypa/setuptools/pull/2143 [^3]: https://www.python.org/dev/peps/pep-0517/ [^4]: https://mail.python.org/archives/list/distutils-sig@python.org/latest?count… [^5]: https://discuss.python.org/c/packaging/14/l/top/yearly?order=posts

11 19

Making setup.py run external command to build
by Julian Smith 02 Apr '21

02 Apr '21

Hello 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, - Jules -- http://op59.net

7 19

multibuild failure
by Robin Becker 25 Feb '21

25 Feb '21

Not sure exactly what broke in the chain of my toolset for building reportlab. I have a github action which fails with the message ls: cannot access /opt/python/cp27-cp27mu/bin: No such file or directory so because I have fixed the checkout version of the multibuild area itself I suppose that something else changed/updated since the last build which was successful on Jan 22. has multibuild / manylinux decided to abandon the python 2.7 version or is there something I can do to get my builds going again? As an aside is it worth trying to fix the version of multibuild or should I just assume that most of the variability will come from the many docker layers that seem to be used. > Digest: sha256:efc8a9832a07678fc17026ab35aa6444c02a665ccd5e6552c90d036045d78b17 > Status: Downloaded newer image for quay.io/pypa/manylinux2010_x86_64:latest > + break > quay.io/pypa/manylinux2010_x86_64:latest > + '[' 5 -eq 0 ']' > + return 0 > + docker run --rm -e 'BUILD_COMMANDS=build_wheel reportlab' -e PYTHON_VERSION=2.7 -e MB_PYTHON_VERSION=2.7 -e UNICODE_WIDTH=32 -e BUILD_COMMIT=HEAD -e CONFIG_PATH=.travis-config.sh -e ENV_VARS_PATH= -e WHEEL_SDIR=wheelhouse -e MANYLINUX_URL= -e BUILD_DEPENDS= -e USE_CCACHE= -e REPO_DIR=reportlab -e PLAT=x86_64 -e MB_ML_VER=2010 -v /home/runner/work/reportlab-mirror/reportlab-mirror:/io -v /home/runner:/parent-home quay.io/pypa/manylinux2010_x86_64 /io/multibuild/docker_build_wrap.sh > ls: cannot access /opt/python/cp27-cp27mu/bin: No such file or directory > Error: Process completed with exit code 2. -- Robin Becker

2 2

Re: Building Pre-releases with setup.cfg
by Matthew Gilbert 10 Feb '21

10 Feb '21

Thanks Jeremy, I will check those out. I thought that maybe there was a simple flag I could pass in to python -m build that would allow me to override a value in setup.cfg, but I should probably read through PEP517/PEP518 in full to get a better overview of this process. > > > From: Jeremy Stanley <fungi(a)yuggoth.org> > Date: Tue, Feb 9, 2021 at 3:26 PM > Subject: [Distutils] Re: Building Pre-releases with setup.cfg > To: <distutils-sig(a)python.org> > > > On 2021-02-09 09:48:31 -0500 (-0500), Matthew Gilbert wrote: > > I'm wondering if it is possibly to build pre-release tags using only a > > setup.cfg file? From > > > https://setuptools.readthedocs.io/en/latest/userguide/distribution.html#tag… > > it seems like this is possible via setup.py, but I was unable to find > > anything related to setup.cfg. > [...] > > Possibly this can be configured using the --config-setting flag but I > have > > been unable to get this to work or find any documentation on it. Ideally > I > > would be able to pass a string so I can build a dev version for testing > > uploads to Test PyPI, e.g. "0.0.1devHASH" > [...] > > I'm probably misunderstanding your question, but typically I've seen > something like PBR or Setuptools-SCM used to automatically calculate > the version at dist build time (including inferring something based > on the number of commits on the branch since the last tag, embedding > abbreviated Git commit IDs, or whatever). > -- > Jeremy Stanley > -- > Distutils-SIG mailing list -- distutils-sig(a)python.org > To unsubscribe send an email to distutils-sig-leave(a)python.org > https://mail.python.org/mailman3/lists/distutils-sig.python.org/ > Message archived at > https://mail.python.org/archives/list/distutils-sig@python.org/message/PUAS… >

1 0

Building Pre-releases with setup.cfg
by Matthew Gilbert 09 Feb '21

09 Feb '21

Hi all, I'm wondering if it is possibly to build pre-release tags using only a setup.cfg file? From https://setuptools.readthedocs.io/en/latest/userguide/distribution.html#tag… it seems like this is possible via setup.py, but I was unable to find anything related to setup.cfg. An abridged version of my setup.cfg file looks like [metadata] name = tester_project version = attr: tester_project.__version__ [bdist_wheel] universal=1 [build-system] requires = setuptools >= 40.9.0 wheel build-backend = setuptools.build_meta Which I was building using $ python -m build --sdist --wheel --outdir dist Possibly this can be configured using the --config-setting flag but I have been unable to get this to work or find any documentation on it. Ideally I would be able to pass a string so I can build a dev version for testing uploads to Test PyPI, e.g. "0.0.1devHASH" Any info or references is much appreciated! Thanks, Matt

2 1

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Distutils-SIG February 2021