buildPython* nowadays consists of many hooks. We've made some changes to those regularly, which impacts the builds, but not so much the interface (removing a hook simply means an option is not being used). The question is where to draw the line to increase the version number.

With the upcoming breaking change it is obvious, the main parameters of the function change. But with e.g. #102949 makeWrapperArgs will probably be renamed. Should we then also increase the version?

A question I guess to ask is "what parts need to be acted upon if they change?".

I think it should always be assumed that a user uses all possible arguments.
If a change in the API requires users to update their code to prevent breakage, then the version should be increased.

A renaming of an argument falls in that category.

Adding an argument ... only if its a mandatory one.
Removing an argument is also fine, as long as it stays backwards compatible.

I think, in case of uncertainty, it's better to increase it than not to increase it.

An alternative might be to not use a version number, but make the function arguments discoverable, or automatically compute some kind of signature on the function argument names.

The build functions depend on the Python-specific hooks as well as the stdenv, which are many pieces of code, some that are hardly used. Doing it that thoroughly is not realistic, or at least, I would say then, it is not public/stable.

Looking back, there are changes every year or so, one bigger than the other. In the last two years or so that has been regarding the introduction of build backends, the rewrite to hooks where options were renamed, and how e.g. python.withPackages behaves.

For 21.03 there is this change, but we will also likely need to change format to default to pyproject which will also be breaking. Then there is the part that I intend to get in changing how we do our wrapping.

To be honest, I think it is much more realistic to rely on NixOS version. In unstable, you just don't know how it looks. We are not a rolling distro after all.

How would I inspect the nixpkgs version of a given pkgs?

> lib.trivial.release will do it then.