Every 2 years #ROS releases a new LTS version requiring a new #Ubuntu version, (with new #Python version), that requires rebuilding my robot Dave and revisiting my installer for the robot hardware Python API, robot files, and sensors.

For years I wondered why I could not just apt install a #GoPiGo3 deb file, or just build a #pyprojecttoml ?

So I built each. Now understand why I must use an install script.

#DexterIndustries devs were genius!

The #EducationalRobot market is a mess.

My day job is all about #Python (which I love). Here are some personal rules, specific to working with Python projects:

* Do **not** install or modify global tools, especially Python itself or any packages. This means a given system might not even **have** a global Python
* Always use virtual environments (`uv` agrees with me, and doesn't need this but). I always set the global environment variable `PIP_REQUIRE_VIRTUALENV`.
* The two rules above mean my virtual environment contains (not via a link, it's really there) Python itself (and of course, of the right version)
* Virtual environments always live **inside** a project directory. Never global.
* Activate virtual environments only **inside** the project directory (`direnv` #direnv makes this easy)
* Don't install (let alone use) #Anaconda, #Miniconda, or #Mamba, because those violate all the rules above (but see the next rule)
* Anaconda-based packages implies a `pixi` #Pixi project (it's the same people, but a better answer, and you still get what you want -- the correct packages)
* No Anaconda-based packages implies a `uv` #UV project
* Always use `pyproject.toml` #pyprojecttoml over any other config file (e.g., `requirements.txt` #requirementstxt), except where things just don't work, such as needing `pyrefly.toml`
* `uv`, `pixi`, and `direnv` must exist outside of any project, so install them at the user level, or else globally if and only if that is appropriate and compelling enough to override rule one

That was a wall of text, but in practice doing it this way is trivial. It's probably **less** work than you have been doing. This post is just about managing your Python versions, environments, and projects. Not about, e.g., using `pre-commit` #precommit, or doing type checking, etc. But if you follow these rules, your work will be easier, faster, more adaptable, and encounter fewer obstacles.

#HowTo

What is the correct way to get information about *my* Python package out of the pyproject.toml file? What I used to do was this:

from importlib.metadata import metadata
my_package_metadata = metadata("my_package")
my_package_homepage = my_package_metadata["home-page"]

But now I'm trying to upgrade Poetry from 1.8 to 2.0 and moved a lot of stuff from tool.poetry to the project section and "home-page" returns None all of a sudden. 🙈

#Python #PyprojectToml #PythonPoetry

Kiedy przypadkowe projekty używające narzędzia do formatowania plików #PyProjectToml, od pewnej osoby z opiniami, i nagle pliki `pyproject.toml` tych wszystkich projektów zaczynają wyglądać, jakby ktoś je wysrał, bo rzeczona osoba zmieniła zdanie, i stwierdziła, że klucze z kropkami dla tabelek #TOML nie są fajne, i lepiej wszystkie wartości w upchnąć w nadrzędnych tabelach. Czy muszę dodawać, że to zupełnie inaczej, niż stosuje się w przykładach dla każdego jednego systemu budowania #PEP517?

Kilka przykładów projektów, w których to nastąpiło (często za sprawą pre-commit):

https://github.com/pypa/virtualenv/commit/7cbed79924b6b6d953ca9ecf40de23a7d3486f57#diff-50c86b7ed8ac2cf95bd48334961bf0530cdc77b5a56f852c5c61b89d735fd711
https://github.com/django-commons/django-debug-toolbar/commit/2990290d43618df5eab357f2a36363186d51d5a8#diff-50c86b7ed8ac2cf95bd48334961bf0530cdc77b5a56f852c5c61b89d735fd711
https://github.com/pytest-dev/pytest/commit/5d5c9dc85850f64621190e62bd20d4b190bdbdb6#diff-50c86b7ed8ac2cf95bd48334961bf0530cdc77b5a56f852c5c61b89d735fd711
https://github.com/prettytable/prettytable/commit/88bebdac122b82af255656513080bdd2c90098d9#diff-50c86b7ed8ac2cf95bd48334961bf0530cdc77b5a56f852c5c61b89d735fd711
https://github.com/python-humanize/humanize/commit/aa3a94e011a795a0551717c5a78a566bc2672390#diff-50c86b7ed8ac2cf95bd48334961bf0530cdc77b5a56f852c5c61b89d735fd711
https://github.com/termcolor/termcolor/commit/9e35c66ab7ad48a33d5c2829dbee02382aa716e5#diff-50c86b7ed8ac2cf95bd48334961bf0530cdc77b5a56f852c5c61b89d735fd711

#Gentoo #Python

When random projects use a certain #PyProjectToml formatter from a certain opinionated upstream, and now all projects suddenly have their `pyproject.toml` files rewritten to look like shit, because opinionated upstream changed their mind, and decided that dotted #TOML table keys are no cool and it's better to inline everything into top-level tables. Which — I should point out — is against the style used in examples of every single #PEP517 build system out there.

Just a few examples where it happened (often via pre-commit hooks):

https://github.com/pypa/virtualenv/commit/7cbed79924b6b6d953ca9ecf40de23a7d3486f57#diff-50c86b7ed8ac2cf95bd48334961bf0530cdc77b5a56f852c5c61b89d735fd711
https://github.com/django-commons/django-debug-toolbar/commit/2990290d43618df5eab357f2a36363186d51d5a8#diff-50c86b7ed8ac2cf95bd48334961bf0530cdc77b5a56f852c5c61b89d735fd711
https://github.com/pytest-dev/pytest/commit/5d5c9dc85850f64621190e62bd20d4b190bdbdb6#diff-50c86b7ed8ac2cf95bd48334961bf0530cdc77b5a56f852c5c61b89d735fd711
https://github.com/prettytable/prettytable/commit/88bebdac122b82af255656513080bdd2c90098d9#diff-50c86b7ed8ac2cf95bd48334961bf0530cdc77b5a56f852c5c61b89d735fd711
https://github.com/python-humanize/humanize/commit/aa3a94e011a795a0551717c5a78a566bc2672390#diff-50c86b7ed8ac2cf95bd48334961bf0530cdc77b5a56f852c5c61b89d735fd711
https://github.com/termcolor/termcolor/commit/9e35c66ab7ad48a33d5c2829dbee02382aa716e5#diff-50c86b7ed8ac2cf95bd48334961bf0530cdc77b5a56f852c5c61b89d735fd711

#Gentoo #Python

I want #pixi to build me a vent. I’ll use it in #pycharm to start but later #pyinstaller. Pixi wants to build things. It’s mad about A which can’t be built. It’s mad about my app, down inside B. Doesn’t like that my #pyprojecttoml is not at the top of B. Doesn’t like that my app can’t be built. My virtual environment has all the external packages it needs, but isn’t working in PyCharm because it doesn’t have any of the things I need from A.

My app _will_ be getting a repo of its own.

I’m doing many things in #pixi that must be wrong because no one discusses them. I have two repos, A and B sitting right next to each other in my file system. Both repos are full of modules that get used here and there. B uses lots of things from A. My actual app lives several directories down inside B. In _that_ directory I have put my #pyprojecttoml. There happen to be other directories next to it. A has no setup.py nor pyproject.toml. Neither A nor B get “built”.

1/2