Distutils-SIG April 2021

distutils-sig@python.org

8 participants
5 discussions

Archive this list & redirect conversation elsewhere?

by Pradyun Gedam

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

1 month

Re: PEP 440 Issue

by Nick Coghlan

Hi Bianca, The ".taskslab11419" section of your version name doesn't meet the requirements for version numbers described in https://www.python.org/dev/peps/pep-0440/#public-version-identifiers, as the only non-numeric text elements permitted are "a" (alpha releases), "b" (beta releases), "c" (release candidates), "dev" (dev releases), and "post" (post-releases). 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). Cheers, Nick. On Tue, 27 Apr 2021 at 14:01, Bianca Reyes <biancamoniquereyes(a)gmail.com> wrote: > 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, > > Bianca > > > > 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. > www.avg.com > <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam…> > <#m_3295279858084880915_m_7829119531011239564_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

1 month, 2 weeks

PSF hiring full-time project/community manager for packaging

by Sumana Harihareswara

Great news: [the Python Software Foundation is **hiring a full-time project manager/community manager for Python's packaging toolchain**](https://pyfound.blogspot.com/2021/04/the-psf-is-hiring-python-…. Thanks to [Bloomberg](https://www.techatbloomberg.com/blog/supporting-the-python-commu… for the funding! Please [read the announcement](https://pyfound.blogspot.com/2021/04/the-psf-is-hiring-python…, check out [the job description](https://www.python.org/jobs/5317/), and spread the news. Please apply by May 18th, 2021. The job is remote and you can apply from anywhere in the world. As the description says: "Total compensation will range from $100k-$125k USD based on qualifications and experience." And you'd report to @EWDurbin Ee W. Durbin III, a colleague I strongly recommend and love working with. I [blogged about why this role is critical](https://www.harihareswara.net/sumana/2021/04/13/1). This new position does build on activities I've led, so I figured I'd explicitly say: I won't be applying for it. I'm going to be, instead, excited to collaborate with this person and help them learn all the stuff I know, so that in the long run, we'll have more people, with that set of skills and domain knowledge, working on Python packaging. I'll concentrate on the Python supply chain security piece specifically (via [the NSF-funded work at NYU](https://discuss.python.org/t/new-packaging-security-funding-nyu/7792)). -- Sumana Harihareswara Changeset Consulting https://changeset.nyc

1 month, 4 weeks

Packaging optional, arch-dependent, pre-built libraries

by Vincent Pelletier

Hello, I'm the author of python-libusb1, a pure-python ctypes wrapper for libusb1. 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[1] 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 against Having nothing to build, I cannot seem to reach the library inclusion step. What is the recommended way of bundling a third-party-built arch-dependent library in an otherwise pure-python package ? [1] https://github.com/vpelletier/python-libusb1/blob/49f7f846bdd3c3d0f2ec3a01c… Regards, -- Vincent Pelletier GPG fingerprint 983A E8B7 3B91 1598 7A92 3845 CAC9 3691 4257 B0C1

1 month, 4 weeks

Making setup.py run external command to build

by Julian Smith

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

2 months, 1 week

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 April 2021