I intend to revert this change.

python-packages.nix is not just about providing importable modules, but it covers all packages that are meant for the development environment bound to a Python version. It's also why e.g. test runners are there (although granted, they typically provide importable modules as well, especially pytest nowadays).

Black is always used in a development environment. If you now create a dev env, and you use the top-level black as input that is going to be problematic. This is the motivation for the split between libraries and dev tools in one hand, and Python programs in the other.

I intend to revert this change.

Thanks for the heads-up!

python-packages.nix is not just about providing importable modules, but it covers all packages that are meant for the development environment bound to a Python version. It's also why e.g. test runners are there (although granted, they typically provide importable modules as well, especially pytest nowadays).

[...] This is the motivation for the split between libraries and dev tools in one hand, and Python programs in the other.

Ah. I wasn't aware of the grouping-together of dev tools with libraries, but I now understand it makes sense for dev tools that must use the same Python version and/or libraries as the project on (or in) which they're used.

By the way, does that go for poetry, too? (Probably not, as the top-level poetry can be used to work with several Python versions within a project, which can be useful.)

Black is always used in a development environment.

I sometimes use black on code I don't otherwise "develop", but I guess that use-case might be somewhat exotic. (And I agree that just using black on that code is, in and of itself, also "development".)

If you now create a dev env, and you use the top-level black as input that is going to be problematic.

Does (or might) black behave differently for different Python versions and / or with different libraries available in the environment? (I guess it could. I recently noticed that isort does, due to how it distinguishes between project-internal imports and third-party imports.) I do agree this PR should be reverted in either case, I just would like to better understand the consequences of using the top-level black it provided.

In principle a build of black can also operate on other Python versions using a flag, but you need to pass that flag then.

Poetry is a bit more complicated. The poetry back-end (build-system) should be in python-packages.nix, but the tool not necessarily, because it is used from the outside to operate on environments. Note also that poetry is maintained using poetry2nix, so its entirely independent from python-packages.nix.