#pyprojecttoml — Public Fediverse posts

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

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

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

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

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.

#HotTo

@mgorny Three of those are by me, sorry you think it look like shit. (I have since reverted some to be more concise: https://github.com/termcolor/termcolor/commit/09ca9cc88b7e31623b8c561aa1fe87383ddd8f72)

I also prefer the original, but #TOML isn't the prettiest and it's much more valuable and maintainable for me to have things consistent and autoformatted than to re-arrange by hand.

Have you tried making suggestions with the formatter? Do you know another formatter that I could use that is better? Is there a #PEP517 / #PyProjectToml style guide?

#Python

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

Tonight's example, that finally got me to toot about it... packaging.

The #poetry documentation for #pyproject.toml describes the #include and #exclude config lists. exclude is #automagically pre-populated with the entries from your VCS ignore file, but, and I quote:

"Explicitly declaring entries in include will negate VCS' ignore settings."

Wanna bet on it? I have an entry in my .gitignore file for `docs`. I explicitly list it in `include`.

3/x

#TOML #PyProjectTOML

Tonight's example, that finally got me to toot about it... packaging.

The #poetry documentation for #pyproject.toml describes the #include and #exclude config lists. exclude is #automagically pre-populated with the entries from your VCS ignore file, but, and I quote:

"Explicitly declaring entries in include will negate VCS' ignore settings."

Wanna bet on it? I have an entry in my .gitignore file for `docs`. I explicitly list it in `include`.

3/x

#TOML #PyProjectTOML

Tonight's example, that finally got me to toot about it... packaging.

The #poetry documentation for #pyproject.toml describes the #include and #exclude config lists. exclude is #automagically pre-populated with the entries from your VCS ignore file, but, and I quote:

"Explicitly declaring entries in include will negate VCS' ignore settings."

Wanna bet on it? I have an entry in my .gitignore file for `docs`. I explicitly list it in `include`.

3/x

#TOML #PyProjectTOML

Tonight's example, that finally got me to toot about it... packaging.

The #poetry documentation for #pyproject.toml describes the #include and #exclude config lists. exclude is #automagically pre-populated with the entries from your VCS ignore file, but, and I quote:

"Explicitly declaring entries in include will negate VCS' ignore settings."

Wanna bet on it? I have an entry in my .gitignore file for `docs`. I explicitly list it in `include`.

3/x

#TOML #PyProjectTOML

Tonight's example, that finally got me to toot about it... packaging.

The #poetry documentation for #pyproject.toml describes the #include and #exclude config lists. exclude is #automagically pre-populated with the entries from your VCS ignore file, but, and I quote:

"Explicitly declaring entries in include will negate VCS' ignore settings."

Wanna bet on it? I have an entry in my .gitignore file for `docs`. I explicitly list it in `include`.

3/x

#TOML #PyProjectTOML

Ugh, prematurely published. For #pixi or #pyprojecttoml users, what’s the first thing I should change to make progress?

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

At #HMCDialogue webinar, learning about a new "single source of truth" format & tool for keeping #ResearchSoftware #Metadata up-to-date across formats: #CitationCFF (#CitationFileFormat), #CodeMeta, #pyprojectTOML, etc.

https://materials-data-science-and-informatics.github.io/somesy/v0.1.0/

@helmholtz_hmc

At #HMCDialogue webinar, learning about a new "single source of truth" format & tool for keeping #ResearchSoftware #Metadata up-to-date across formats: #CitationCFF (#CitationFileFormat), #CodeMeta, #pyprojectTOML, etc.

https://materials-data-science-and-informatics.github.io/somesy/v0.1.0/

@helmholtz_hmc

At #HMCDialogue webinar, learning about a new "single source of truth" format & tool for keeping #ResearchSoftware #Metadata up-to-date across formats: #CitationCFF (#CitationFileFormat), #CodeMeta, #pyprojectTOML, etc.

https://materials-data-science-and-informatics.github.io/somesy/v0.1.0/

@helmholtz_hmc

At #HMCDialogue webinar, learning about a new "single source of truth" format & tool for keeping #ResearchSoftware #Metadata up-to-date across formats: #CitationCFF (#CitationFileFormat), #CodeMeta, #pyprojectTOML, etc.

https://materials-data-science-and-informatics.github.io/somesy/v0.1.0/

@helmholtz_hmc

At #HMCDialogue webinar, learning about a new "single source of truth" format & tool for keeping #ResearchSoftware #Metadata up-to-date across formats: #CitationCFF (#CitationFileFormat), #CodeMeta, #pyprojectTOML, etc.

https://materials-data-science-and-informatics.github.io/somesy/v0.1.0/

@helmholtz_hmc

I’ve been loving using #hatch when doing anything in python.

The way environments work can be a bit confusing at first. I was tempted to activate them and then `pip install` things myself but turns out you don’t need to worry about it at all. You basically just add your dependencies to the pyproject.toml file and hatch takes care of the rest.

#python #pyprojecttoml #packaging #development #programming #code

I think I’m starting to like this pyproject.toml thing 🤔

#python #pyprojecttoml #toml #development #package #application

"Let's face it, the "PyPA’s stance" is just an opinion of a small number of community members which clearly contradicts the process actually happening in the community and the request for that being highly spread."

https://github.com/python/mypy/issues/5205#issuecomment-786556051

#python #pypa #mypy #pyprojecttoml