Just published an article to understand Python Project Management and Packaging, illustrated with uv

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

Hey everyone,

I’ve just finished writing the first part of my comprehensive guide on Python project management and packaging. Now that I think about it, I think it's more an article to understand the many concepts of Python packaging and project management more than a guide in and of itself.

The article: A Comprehensive Guide to Python Project Management and Packaging: Concepts Illustrated with uv – Part I

In this first part, I focused on:

- The evolution of Python packaging standards through key PEPs.

- Detailed explanations of the main concepts like `pyproject.toml`, the packaging nomenclature, the dependency groups, locking and syncing etc.

- An introduction to `uv` and how it illustrates essential packaging concepts.

- Practical workflows using `uv` that I use with data science projects.

Mainly what it lacks is a deeper section or paragraph on workspaces, scripts, building and publishing. That's for part 2!

Working on this article was mainly journey for me through the various PEPs that have shaped the current Python packaging standards. I delved into the history and rationale behind these PEPs. I just wanted to understand. I wanted to understand all the discussions around packaging. That's something we deal with daily, so I wanted to deeply understand every concept that's related to Python projects or packages. The PEPs, and my own experience, helped me understand why certain changes were necessary and how they effectively resolved previous issues. It was enlightening to see how the thoughtful decision-making and the understanding of developers' needs. And I gained a deeper appreciation for how PEPs are organized and how they think external stuff like the existing tools and how they leave room for future improvement and standardization and for tools to innovate.

It was a pleasure both writing and reading through the material. I don’t expect everyone to read it in its entirety since it’s quite lengthy, and I’m sure my writing style has room for improvement. However, I believe you can easily pick up valuable bits of information from it. For those who are really interested, I highly recommend diving into the PEPs directly to get the most accurate and detailed insights!

[-]

ArchFFY00@reddit

While reading your article, I was confused around your discussion of "editable dependencies".

That essentially just refers to a dependency that has been installed in an "editable" mode. It is not really a thing on its own, and doesn't need to be unless you are talking about tooling that provisions environments.

In your article you do go into environment provisioning, mentioning lockfiles, etc. but you bring these concepts back to areas where they do belong. For example, you mention that there is no standardization for specifying "editable dependencies", hinting that is a missing feature, but that would belong in something like a lockfile format, which is something that isn't standardized.

Within all standardized formats, there's no feature disparity when it comes to "editable dependencies". You are able to specify project/group dependencies, and you are able to install projects in an "editable" mode.

[-]