Sadly pyproject-nix does not support dynamic attributes. The FAQ is not helpful ass it is suggesting replacing dynamic attribute with hard-coded value. Which completely misses the point of dynamic attributes.
Is it somehow possible to retrieve the latest git tag on the nix level, so it can be injected to the lib.buildPythonPackage?
I see with self.sourceInfo it is possible to get the rev/dirtyRev. Is it somehow possible to get the git tag out of it to?
I see it may require some changes to https://github.com/NixOS/nix/blob/128688db63545c84df443b97e855c98cbac6a25b/src/libfetchers/git.cc to fetch more git metadata
The change wouldn’t be accepted even if you proposed it. It violates reproducibility.
Suppose commit abc is currently tag v1.0, commit def comes after it, and commit ghi after that. I build commit ghi, I get something with v1.0.post<whatever> in my build result. Then someone tags def as v1.1. Now I build ghi again, and get v1.1post<whatever> instead. I built the same commit, but got a different result. This is a big no no.
Put simply, if this can somehow be done, the nix developers would consider that a bug that would need fixing.
“Ref” is a flake URL reference here, not a git one. “Resolved ref” is determining the immutable URL to use (since unresolved flake refs can use things like tags, branches, etc. that are clearly mutable).
It seems like something is not clicking here - the entire point of a NAR hash is immutability under the same (resolved) URL reference. If data changes out under you, that violates a core promise that nix makes about reproducibility of fixed-output store paths. Tags can change out under you; commit hashes cannot. The content of a flake should not change based on when you fetch it, given a locked flakeref. Hence tags are not something that should be stored, and if it is, and nix devs know about it, it will be removed.
Write the versions in the source code. That’s the way.
If you really want to save yourself the typing, you could do it in a pre-commit hook or something. (On second thought, the tag wouldn’t, and couldn’t, exist yet at the time you were committing, so nvm)
I can store version in the version file for example. Will be sort of burden, but kinda acceptable. Sadly this creates the problem: how to determine if the build is happening on this version, or some later commit.
Another way, DETERMINISTIC this time, will be reading git log, till the Release version (\d+.\d+.\d+) commit. I don’t see it easy doable either.
Currently tinkering with builtins.exec, the problem is accessing the repo location in there. Execution happens on current directory, which does not have to be the repo itself.
Flakes build from just the commit, not its history. They have to build the same from a shallow checkout as a full one, for example.
Also, builtins.exec is dependent on a disabled-by-default feature, allow-unsafe-native-code-during-evaluation, whose name explicitly marks it as unsafe because it violates the guarantees nix is built for. (And because if it’s enabled, anybody whose nix code you evaluate can do a rm -rf / on you if they want…)
Write yourself a script that updates the version information in the source, commits, and tags the commit, and use that for releasing. Then just live with the fact that you don’t have sequence information in version numbers. You can include the git commit id, and that’s enough to identify what’s being used.
