Remove the "Authority" from Packaging - Packaging - Discussions on Python.org
Turns out the A in PyPA, meaning "authority", was originally intended as a joke. TIL.
Public
Rye and uv: August is Harvest Season for Python Packaging
Blog post about the state of Python packaging in 2024, with a particular emphasis on how uv is going (and in part rye too).
Phylum Discovers Dozens More PyPI Packages Attempting to Deliver W4SP Stealer in Ongoing Supply-Chain Attack
"Last week, our automated risk detection platform alerted us to some suspicious activity in dozens of newly published PyPI packages. It appears that these packages are a more sophisticated attempt to deliver the W4SP Stealer on to Python developer’s machines by hiding a malicious import . Join us here on the Phylum research team as we investigate these new and shifting tactics the attacker is using to deploy W4SP stealer in this supply-chain attack."
Should You Use Upper Bound Version Constraints?
I don't agree with much of this, but I recognise it's a valid position. To quote from the TL;DR at the end:
"Capping dependencies has long term negative effects, especially for libraries, and should never be taken lightly. A library is not installed in isolation; it has to live with other libraries in a shared environment. Only add a cap if a dependency is known to be incompatible or there is a high (>75%) chance of it being incompatible in its next release. Do not cap by default - capping dependencies makes your software incompatible with other libraries that also have strict lower limits on dependencies, and limits future fixes. Anyone can fix a missing cap, but users cannot fix an over restrictive cap causing solver errors. It also encourages hiding issues until they become harder to fix, it does not scale to larger systems, it limits your ability to access security and bugfix updates, and some tools (Poetry) force these bad decisions on your downstream users if you make them. Never cap Python, it is fundamentally broken at the moment. Also, even packing capping has negative consequences that can produce unexpected solves."
What Are Python Wheels and Why Should You Care? – Real Python
Pretty comprehensive article covering the concept of Python "wheels".
pip.wtf: Inline dependencies for small Python scripts
A tool to include dependencies with a Python script, without the packaging faff. Not sure I need it, not even sure I want it, but damn do I love how it's written up and introduced. I feel the annoyance.
Packing Python Projects
This tutorial walks you through how to package a simple Python project. It will show you how to add the necessary files and structure to create the package, how to build the package, and how to upload it to the Python Package Index (PyPI).
How We Executed A Critical Supply Chain Attack On Pytorch
"Four months ago, Adnan Khan and I exploited a critical CI/CD vulnerability in PyTorch, one of the world’s leading ML platforms. Used by titans like Google, Meta, Boeing, and Lockheed Martin, PyTorch is a major target for hackers and nation-states alike.
Thankfully, we exploited this vulnerability before the bad guys.
Here is how we did it."
Python Packaging, One Year Later: A Look Back at 2023 in Python Packaging
How to improve Python packaging, or why fourteen tools are at least twelve too many
"Join me on a journey through packaging in Python and elsewhere. We’ll start by describing the classic packaging stack (involving setuptools and friends), the scientific stack (with conda), and some of the modern/alternate tools, such as Pipenv, Poetry, Hatch, or PDM. We’ll also look at some examples of packaging and dependency-related workflows seen elsewhere (Node.js and .NET). We’ll also take a glimpse at a possible future (with a venv-less workflow with PDM), and see if the PyPA agrees with the vision and insights of eight thousand users."