buck2 --version logic in OSS build is strange and non-standard

[thoughtpolice]

Consider a user who uses the brand-spankin'-new buck2 package from Nixpkgs, based on tag 2023-07-11:

austin@GANON:~/src/nixpkgs$ nix-build -A buck2
/nix/store/r4g72h2h8p6isxym6qg4fgdwynn3dq65-buck2-unstable-2023-07-11
austin@GANON:~/src/nixpkgs$ ./result/bin/buck2 --version
buck2 228d33252457c4f2697eb4c8376e6dde58de2dec <local>

This is confusing, and less than ideal.

Typically, the expectation of a --version flag is that it will output, at minimum, some information that can be cross-correlated to an exact build identifier (AKA git commit hash), and, in the case of a build that has a repository tag associated with it, the name of the tag itself.

In this case, I'd expect buck2 --version to have 2023-07-11 in it somewhere, even if the other stuff remained, as that is the name of the tag from which we download the buck2 binaries.

More broadly, aside from just UX, some automatic and turnkey tools that distribution/packaging engineers use behind the scenes to make sausage tend to rely on behavior like that for automatic updates. For example, there are opt-in package testing harnesses in Nixpkgs that will automatically ensure a build produces working binaries, with --version output that is expected to match the package version. That kind of feature is really useful to help keep mistakes down and UX consistent for users.

I tend to like the way systems like GNU coreutils or GHC do it: the full --version string includes the version/build info, application name, and copyright text. There can be a separate supported flag for only displaying the exact version string and nothing else; GHC called this --numeric-version, for instance.

Hypothetical example of what would be good:

austin@GANON:~$ buck2 --version
buck2 version 2023-07-11 (prerelease)
Copyright (C) 2022-2023 The Buck2 Developers
License: MIT-or-Apache 2.0

austin@GANON:~$ buck2 --version-tag
2023-07-11

---

As a side note, the version logic is really confusing when I last remember looking at it; it does stuff like hash /proc/self/exe, use a Git hash, and also has another fallback I think? I could look over the code but the details aren't so important; I suspect it's mainly that way so that the Meta team can hunt down whatever random version of a buck2 binary someone is using when they complain, and trace it back to a build. But for OSS builds, we don't really need any of that, so maybe it should be under fbcode_build if that can be done.

[ndmitchell]

Honestly, I don't think internally we have ever used the version number. We do build stamping so have the date a version was compiled available by other means, and tend to use that. So the version number is mostly used to confirm that the buck2 server you are talking to is the one you expect, meaning a hash of the binary is fine.

Agreed, we could do a lot better here! Maybe our buck2_release.yml script should pass in a date that gets printed out? CC @themarwhal

[dbort]

Printing a predictable version would help us out a lot. Since the buck2 version seems to be tied to the prelude version (we've had compatibility problems if they're not updated together), we need to make sure that our users have the correct version installed, and we try to install that version for them. But doing so requires that we manage our own map of version hashes: https://github.com/pytorch/executorch/blob/cde514ca0898ba93d95158b3dbe9ecd2a2b9f32c/build/resolve_buck.py#L65

It'd be so much easier for us if we could ask the buck2 tool what version it is without needing to manually update these hashes when moving to a new version. Or even if all of the different platforms agreed on a hash, then we'd only need to manage a single hash.

cc: @GregoryComer