search

NixOS / nixpkgs

Nix Packages collection & NixOS
MIT License
16.51k stars 12.99k forks source link

Wrong date in `crystal --version` #306765

Open straight-shoota opened 2 months ago

straight-shoota commented 2 months ago

The crystal compiler shows a date next to the version number when running crystal --version.

It should usually be the date of the source version, typically the release date. When building the compiler, this date is taken from the enviornment variable SOURCE_DATE_EPOCH and baked into the binary.

Apprently this configuration is incorrect and points to 1980-01-01. If no date information is available, it should be omitted (i.e. SOURCE_DATE_EPOCH should be unset or empty).

$ nix-shell -p crystal -I nixpkgs=channel:nixos-23.11 --command "crystal --version"
Crystal 1.9.2 (1980-01-01)

LLVM: 15.0.7
Default target: x86_64-unknown-linux-gnu

If no date information is available, it would be better to omit it (i.e. unset SOURCE_DATE_EPOCH or make its value empty). It would be better of course to include the correct release date.

Note for older versions it appears to have a different date, although still not the correct one (1.8.1 is from April 2023).

$ nix-shell -p crystal -I nixpkgs=channel:nixos-23.05 --command "crystal --version"
Crystal 1.8.1 (2023-12-27)

LLVM: 15.0.7
Default target: x86_64-unknown-linux-gnu
Atemu commented 2 months ago

Apprently this configuration is incorrect and points to 1980-01-01. If no date information is available, it should be omitted (i.e. SOURCE_DATE_EPOCH should be unset or empty).

This is intentional. SOURCE_DATE_EPOCH is set to 315532800 by default in order to facilitate reproducible builds. Not setting it causes some build systems to use the current date at build time instead which is obviously not reproducible.

If you want a different date, you can declare SOURCE_DATE_EPOCH to be any epoch you want. This would however be yet another manual step in the update process. Given that this is merely an extremely minor cosmetic issue, that is not a good trade-off to make.

Other hacky solutions I've seen (and I think even done myself) is to keep the .git dir in fetchGit, record the latest commit's date into a file and then remove .git. That also has issues though.

If you could automate updating SOURCE_DATE_EPOCH with the src, it might be acceptable to have a SOURCE_DATE_EPOCH that corresponds with the upstream release date but until then, I'll close this as WONTFIX.

straight-shoota commented 2 months ago

I understand the need for a default configuration.

However it seems odd to have a nonsensical date when it can easily be prevented. If SOURCE_DATE_EPOCH is unset while building the Crystal package, no date will be shown. So this looks like an easy improvement.

It sounds like a reasonable idea to put the SOURCE_DATE_EPOCH value into the source release. I'll look into that. Is there any established mechanism for that? I'd probably put it in a file called src/SOURCE_DATE_EPOCH, right next to src/VERSION.

Atemu commented 2 months ago

If SOURCE_DATE_EPOCH is unset while building the Crystal package, no date will be shown. So this looks like an easy improvement.

If that is indeed the case for this specific package, explicitly unsetting SOURCE_DATE_EPOCH would be fine IMO.

straight-shoota commented 1 month ago

Starting with the next Crystal release (1.13.0), the source date is exposed in src/SOURCE_DATE_EPOCH (https://github.com/crystal-lang/crystal/pull/14574).