Just published part 2 of my articles on Python Project Management and Packaging, illustrated with uv

Posted by ReinforcedKnowledge@reddit | Python | View on Reddit | 8 comments

Hey everyone,

Just finished the second part of my comprehensive guide on Python project management. This part covers both building packages and publishing.

It's like the first article, the goal is to dig in the PEPs and specifications to understand what the standard is, why it came to be and how. This is was mostly covered in the build system section of the article.

The article: https://reinforcedknowledge.com/a-comprehensive-guide-to-python-project-management-and-packaging-concepts-illustrated-with-uv-part-2/

I have tried to implement some of your feedback. I worked a lot on the typos (I believe there aren't any but I may be wrong), and I tried to divide the article into three smaller articles: - Just the high level overview: https://reinforcedknowledge.com/a-comprehensive-guide-to-python-project-management-and-packaging-part-2-high-level-overview/ - The deeper dive into the PEPs and specs for build systems: https://reinforcedknowledge.com/a-comprehensive-guide-to-python-project-management-and-packaging-part-2-source-trees-and-build-systems-interface/ - The deeper dive into PEPs and specs for package formats: https://reinforcedknowledge.com/a-comprehensive-guide-to-python-project-management-and-packaging-part-2-sdists-and-wheels/

In the parent article there are also two smalls sections about uv build and uv publish. I don't think they deserve to be in a separate smaller article and I included them for completeness but anyone can just go uv help <command> and read about the command and it'd be much better. I did explain some small details that I believe that not everyone knows but I don't think it replaces your own reading of the doc for these commands.

In this part I tried to understand two things:

1- How the tooling works, what is the standard for the build backend, what it is for the build frontend, how do they communicate etc. I think it's the most valuable part of this article. There was a lot to cover, the build environment, how the PEP considered escape hatches and how it thought of some use cases like if you needed to override a build requirement etc. That's the part I enjoyed reading about and writing. I think it builds a deep understand of how these tools work and interact with each other, and what you can expect as well.

There are also two toy examples that I enjoyed explaining, the first is about editable installs, how they differ when they're installed in a project's environment from a regular install.

The second is customising the build process by going beyond the standard with custom hooks. A reader asked in a comment on the first part about integrating Pyarmor as part of its build process so I took that to showcase custom hooks with the hatchling build backend, and made some parallels with the specification.

2- What are the package formats for Python projects. I think for this part you can just read the high level overview and go read the specifications directly. Besides some subsections like explaining some particular points in extracting the tarball or signing wheels etc., I don't think I'm bringing much here. You'll obviously learn about the contents of these package formats and how they're extracted / installed, but I copy pasted a lot of the specification. The information can be provided directly without paraphrasing or writing a prose about it. When needed, I do explain a little bit, like why installers must replace leading slashes in files when installing a wheel etc.

I hope you can learn something from this. If you don't want to read through the articles don't hesitate to ask a question in the comments or directly here on Reddit. I'll answer when I can and if I can 😅

I still don't think my style of writing is pleasurable or appealing to read but I enjoyed the learning, the understanding, and the writing.

And again, I'l always recommend reading the PEPs and specs yourself, especially the rejected ideas sections, there's a lot of insight to gain from them I believe.