Mailman 3 - Distutils-SIG

Provide a way to bundle and extract license files
by Steve Jorgensen 07 Mar '20

07 Mar '20

The project I am working on now needs to include license files for all of the 3rd party code that it includes. Since license files are not included in distribution packages, the process for doing this is exceedingly complex, error prone, and in some cases, impossible. The build process builds URLs to license files in package source code repositories based on version number, but this is dependent upon several things… 1. The source code repository is accessible via the Internet and still exists. 2. There is a tag for each version (not always true). 3. Tags follow a consistent naming pattern with respect to version numbers (not always true). I believe that it makes sense to provide a standard means for distribution packages to include license files and then encourage package authors to use it.

4 8

[setuptools] Install entry point only if extras_require are satisfied?
by Jonatan Palsson 06 Mar '20

06 Mar '20

Hi, I'm modifying a python project which uses setuptools for installation. The project installs an entry point as such: setup_args["entry_points"] = { "console_scripts": ["w1thermsensor = w1thermsensor.cli:cli [CLI]"] } where [CLI] is a reference to an extra_requires entry. This entry looks like this: extras_require=dict(CLI="click>=7.0") With these two lines, the current behavior is that the w1thermsensor entry point is *always* installed when "setup.py install" is invoked, but the entry point will cause an error if its dependencies are not available. I would like to change the behavior, so that the entry point is *not installed* if the extra dependencies are not available (and perhaps also show a warning, indicating that this entry point has not been installed). How can I do this? Cheers, Jonatan

2 1

The base docker images for manylinux appear to be private
by Sylvain Corlay 01 Mar '20

01 Mar '20

It seems that the base images used for manylinux wheels are not publicly available. For example, https://quay.io/pypa/manylinux2010_centos-6-no-vsyscall gives a 403 error ("you are not authorized to view this resource"). I think that it would make sense for reproducibility purposes to make these images public. (I have opened an issue about this on the GitHub repository: https://github.com/pypa/manylinux/issues/481). Best,

5 8

Mailing list
by Daniel Scott 26 Feb '20

26 Feb '20

Sent from Yahoo Mail on Android

1 0

parver: parse and manipulate PEP 440 version numbers
by Frazer McLean 21 Feb '20

21 Feb '20

Hi, parver is my package for parsing and manipulating PEP 440 version numbers. I have just released version 0.3. For more information: PyPI: https://pypi.org/project/parver/ Repository: https://github.com/RazerM/parver Documentation: https://parver.readthedocs.io/en/latest/ Thanks, Frazer

2 2

PyCon US 2020 Packaging Summit: Registration and Topic Proposal
by Paul Ganssle 19 Feb '20

19 Feb '20

/Cross-posting this announcement to both distutils-SIG and discourse. The main discussion thread should be on the discourse <https://discuss.python.org/t/pycon-us-2020-packaging-summit-registration-an…>./ Greetings one and all, Though each of us cuts our own path through the harrowing jungle that is the days of our lives, we are all inevitably drawn closer and closer to a single fate; yes, of course I am talking about PyCon 2020’s Packaging Summit! April is looming on the horizon, threatening to take us unawares, but we are a crafty sort, and have prepared to meet its ambush with a secret weapon: DILIGENT PREPARATION AND SPREADSHEETS! In my last announcement, I asked that you save the date: *Thursday, April 16, 2020*, but provided you no other action items. I am now coming to you with TWO actions that you can take. /If you don’t know what the packaging summit is, please see the website for more details <https://us.pycon.org/2020/hatchery/packaging>./ 1. *Register*! This year we will be collecting registration ahead of time, and like the Language Summit we will be curating the list of attendees to try and maximize the effectiveness of the limited time we have for these discussions. In addition to people actually working on packaging tools, we’re also looking to see people with many different perspectives participating in the discussions, so if you are on the fence as to whether or not you qualify but you’re interested in participating, please register. You can register at http://bit.ly/python-packaging-summit-2020-reg Registration is open /now/ and we will close the registration form on *March 7th, 2020*. All registration decisions should be finished by *March 15th, 2020*. 2. *Propose topic for discussion*! In previous years, topics were proposed in the room or ahead of time on discourse. This year, we’ll be collecting discussion topics with something closer to a private Call for Proposals, and then releasing all the discussion topics for public voting at the same time. We’ll be doing it this way to prevent biasing certain selections based on their position in the voting list or length of time available to be voted on. Topic suggestions will be evaluated independent of the submitter; please propose any topic you would like to see discussed — you don’t have to be the driver of an idea to propose it. We will schedule about 5 minutes at the beginning of each discussion period for someone to give a quick introduction to the topic. By default the person (or people) who proposed the topic will be responsible for either giving that introduction or delegating the task to someone else, but if one of your proposals was selected and you cannot present or find someone to present, the organizers will find someone to give the introduction. You may find the topic proposal form at http://bit.ly/python-packaging-summit-2020-topics Topic proposal is open /now/ and will close on *March 7th, 2020*. Topic voting is expected to run from March 9th - March 30th. This and other information is available at our website: https://us.pycon.org/2020/hatchery/packaging/ If you have any questions or concerns, feel free to respond on the discourse <https://discuss.python.org/t/pycon-us-2020-packaging-summit-registration-an…> or to contact me or one of the other organizers.

1 0

Mailing list
by Daniel Scott 19 Feb '20

19 Feb '20

Sent from Yahoo Mail on Android

1 0

Surviving a Compromise of PyPI - PEP 458 and 480
by Vladimir Diaz 12 Feb '20

12 Feb '20

Hello everyone, I am a research programmer at the NYU School of Engineering. My colleagues (Trishank Kuppusamy and Justin Cappos) and I are requesting community feedback on our proposal, "Surviving a Compromise of PyPI." The two-stage proposal can be reviewed online at: PEP 458 http://legacy.python.org/dev/peps/pep-0458/ PEP 480 http://legacy.python.org/dev/peps/pep-0480/ Summary of the Proposal: "Surviving a Compromise of PyPI" proposes how the Python Package Index (PyPI) can be amended to better protect end users from altered or malicious packages, and to minimize the extent of PyPI compromises against affected users. The proposed integration allows package managers such as pip to be more secure against various types of security attacks on PyPI and defend end users from attackers responding to package requests. Specifically, these PEPs describe how PyPI processes should be adapted to generate and incorporate repository metadata, which are signed text files that describe the packages and metadata available on PyPI. Package managers request (along with the packages) the metadata on PyPI to verify the authenticity of packages before they are installed. The changes to PyPI and tools will be minimal by leveraging a library, The Update Framework <https://github.com/theupdateframework/tuf>, that generates and transparently validates the relevant metadata. The first stage of the proposal (PEP 458 <http://legacy.python.org/dev/peps/pep-0458/>) uses a basic security model that supports verification of PyPI packages signed with cryptographic keys stored on PyPI, requires no action from developers and end users, and protects against malicious CDNs and public mirrors. To support continuous delivery of uploaded packages, PyPI administrators sign for uploaded packages with an online key stored on PyPI infrastructure. This level of security prevents packages from being accidentally or deliberately tampered with by a mirror or a CDN because the mirror or CDN will not have any of the keys required to sign for projects. The second stage of the proposal (PEP 480 <http://legacy.python.org/dev/peps/pep-0480/>) is an extension to the basic security model (discussed in PEP 458) that supports end-to-end verification of signed packages. End-to-end signing allows both PyPI and developers to sign for the packages that are downloaded by end users. If the PyPI infrastructure were to be compromised, attackers would be unable to serve malicious versions of these packages without access to the project's developer key. As in PEP 458, no additional action is required by end users. However, PyPI administrators will need to periodically (perhaps every few months) sign metadata with an offline key. PEP 480 also proposes an easy-to-use key management solution for developers, how to interface with a potential build farm on PyPI infrastructure, and discusses the security benefits of end-to-end signing. The second stage of the proposal simultaneously supports real-time project registration and developer signatures, and when configured to maximize security on PyPI, less than 1% of end users will be at risk even if an attacker controls PyPI and goes undetected for a month. We thank Nick Coghlan and Donald Stufft for their valuable contributions, and Giovanni Bajo and Anatoly Techtonik for their feedback. Thanks, PEP 458 & 480 authors.

7 53

Deleted PyPI project
by sabrygad＠buffalo.edu 12 Feb '20

12 Feb '20

Hi; I am new to PyPI and deleted my project (pyhma) by mistake. Is there a way to allow me to create it again with the same name? We can not change the name as it is part of a code paper under the same name. Thanks; Sabry

4 5

travis failures
by Robin Becker 11 Feb '20

11 Feb '20

I have just seen all my manylinux builds fail at https://travis-ci.org/MrBitBucket/reportlab-mirror they all seem to fail in the multibuild install_run phase. I haven't altered anything related to .travis.yml since the previous run on Jan 17th. All the failures seem to relate to a cdn bucket the runs all end with something like this Looking in links: https://5cf40426d9f06eb7461d-6fe47d9331aba7cd62fc36c7196769e4.ssl.cf2.rackc… 1483Collecting pillow 1484 Downloading Pillow-6.2.2-cp27-cp27m-manylinux1_i686.whl (2.0 MB) 1485Installing collected packages: pillow 1486Successfully installed pillow-6.2.2 1487DEPRECATION: Python 2.7 reached the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 is no longer maintained. A future version of pip will drop support for Python 2.7. More details about Python 2 support in pip, can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support 1488ERROR: You must give at least one requirement to install (maybe you meant "pip install https://5cf40426d9f06eb7461d-6fe47d9331aba7cd62fc36c7196769e4.ssl.cf2.rackc…"?) but I cannot find that in my .yml or the travis config file which I use. Any idea what could be causing this? -- Robin Becker

2 5