Mailman 3 - Distutils-SIG

Shutting down distutils-sig, for real
by Andrew M. Kuchling Dec. 30, 2021

Dec. 30, 2021

Shutting down the distutils-sig mailing list has been suggested since December 2020, notably by Pradyun Gedam who also raised the issue again in May 2021. However, everyone seems nervous about making the final decision. Well, I'm still the moderator of the list, so I'm happy to make that call: let's shut the list down for 2021! Steps I'll take: * Edit the list's one-line description to "Former list for Python packaging ecosystem discussion. Now archived." * Edit the list's long description to be in the past tense, and to point people at the right category on discuss.python.org. * Change the default action for the list for members and non-members to 'Reject (with notification)'. * Clear the list of members by unsubscribing everyone. * Clear the email addresses listed in the 'accept these nonmembers' field. * Submit a PR for the Python docs to remove 'distutils-sig(a)python.org' as author of a few sections. Are there other PyPA repos that might reference the list? I'll aim to do all of these tomorrow, on the last day of year. --amk

3 2

ANN: distlib 0.3.4 released on PyPI
by Vinay Sajip Dec. 8, 2021

Dec. 8, 2021

I've recently released version 0.3.4 of distlib on PyPI [1]. For newcomers, distlib is a library of packaging functionality which is intended to be usable as the basis for third-party packaging tools. The main changes in this release are as follows: * Fixed #153: Raise warnings in get_distributions() if bad metadata seen, but keep going. * Fixed #154: Determine Python versions correctly for Python >= 3.10. * Updated launcher executables with changes to handle duplication logic. Code relating to support for Python 2.6 was also removed (support for Python 2.6 was dropped in an earlier release, but supporting code wasn't removed until now). A more detailed change log is available at [2]. Please try it out, and if you find any problems or have any suggestions for improvements, please give some feedback using the issue tracker! [3] Regards, Vinay Sajip [1] https://pypi.org/project/distlib/0.3.4/ [2] https://distlib.readthedocs.io/en/0.3.4/ [3] https://bitbucket.org/pypa/distlib/issues/new

1 0

PEP 440
by Johnathan Irvin Nov. 16, 2021

Nov. 16, 2021

Noticed the link was broken for RFC 2119. I believe it should be https://datatracker.ietf.org/doc/html/rfc2119 and currently points to http://tools.ietf.org/html/rfc2119.html Thanks, Johnathan Irvin https://twitter.com/_JohnnyIrvin https://www.linkedin.com/in/johnnyirvin/

3 2

Question from a Beginner
by Sonic Emitter3000 Sept. 23, 2021

Sept. 23, 2021

Hello, hope you're doing well. I greatly appreciate the effort of you people to make open source projects like you do, but I must ask. I have heard that security is quite lax when installing modules using the most popular sites for Python modules. Would you know of how I would protect myself more from potentially malicious fakes of popular Python modules?

2 2

ANN: distlib 0.3.3 released on PyPI
by Vinay Sajip Sept. 22, 2021

Sept. 22, 2021

I've recently released version 0.3.3 of distlib on PyPI [1]. For newcomers, distlib is a library of packaging functionality which is intended to be usable as the basis for third-party packaging tools. The main changes in this release are as follows: * Fixed #152: Removed splituser() function which wasn't used and is deprecated. * Fixed #149: Handle version comparisons correctly in environment markers. * Add ARM-64 launchers and support code to use them. Thanks to Niyas Sait and Adrian Vladu for their contributions. * Fixed #148: Handle a single trailing comma following a version. Thanks to Blazej Floch for the report and suggested fix. * Fixed #150: Fix incorrect handling of epochs. * Reverted handling of tags for Python >= 3.10 (use 310 rather than 3_10). This is because PEP 641 was rejected. * Added a GitHub Actions workflow to perform tests. A more detailed change log is available at [2]. Please try it out, and if you find any problems or have any suggestions for improvements, please give some feedback using the issue tracker! [3] Regards, Vinay Sajip [1] https://pypi.org/project/distlib/0.3.3/ [2] https://distlib.readthedocs.io/en/0.3.3/ [3] https://bitbucket.org/pypa/distlib/issues/new

1 0

ANN: distlib 0.3.2 released on PyPI
by Vinay Sajip May 31, 2021

May 31, 2021

I've recently released version 0.3.2 of distlib on PyPI [1]. For newcomers, distlib is a library of packaging functionality which is intended to be usable as the basis for third-party packaging tools. The main changes in this release are as follows: * Fixed #139: improved handling of errors related to the test PyPI server. * Fixed #140: allowed "Obsoletes" in more scenarios, to better handle faulty metadata already on PyPI. * Fixed #141: removed unused regular expression. * Fixed #143: removed normcase() to avoid some problems on Windows. * Fixed #146: added entry for SourcelessFileLoader to the finder registry. * Fixed #147: permission bits are now preserved on POSIX when installing from a wheel. * Made the generation of scripts more configurable. * Added support for manylinux wheel tags. A more detailed change log is available at [2]. Please try it out, and if you find any problems or have any suggestions for improvements, please give some feedback using the issue tracker! [3] Regards, Vinay Sajip [1] https://pypi.org/project/distlib/0.3.2/ [2] https://distlib.readthedocs.io/en/0.3.2/ [3] https://bitbucket.org/pypa/distlib/issues/new

1 0

Archive this list & redirect conversation elsewhere?
by Pradyun Gedam May 9, 2021

May 9, 2021

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

Re: PEP 440 Issue
by Nick Coghlan April 27, 2021

April 27, 2021

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

2 1

PSF hiring full-time project/community manager for packaging
by Sumana Harihareswara April 15, 2021

April 15, 2021

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 0

Packaging optional, arch-dependent, pre-built libraries
by Vincent Pelletier April 15, 2021

April 15, 2021

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

4 7