Undetected git version should be a run-time error

[eschnett]

I built Julia from a shallow git repository. There was a build-time warning about not being able to determine the git version number, which I saw and ignored, since I didn't know the cause for the warning. At run time, many packages (e.g. HDF5, MPI) didn't install, and I received very strange warnings from Compat.

It turns out that Compat looks at the git version number to determine what features to provide in which way, and git needs a non-shallow repo to be able to determine the version number. I didn't know either of these facts initially.

With a shallow git repo, Julia reports its version as 0.5.0-dev, which looks inconspicious. However, with a non-shallow repo, the version number is e.g. 0.5.0-dev+3263, and Compat requires this additional bit to work.

Since Compat is so fundamental, this deserves a much more visible warning, or error, and an explanation when it occurs.

I can think of several solutions:

• Abort Julia build with an error if the git repo is shallow
• Abort Compat package with an error and an explanation when the version number has this problem
• Don't use version numbers to determine Compat's behaviour; instead, test which features are available
• Create a "tag" (add a new global constant with a certain name) each time an incompatible change is made; Compat can then look for these tags instead of at the git version number

[tkelman]

Partially a dupe of #10851. Shallow checkouts or no-git builds are fine if you're building from a release tag, but going to hit this problem anywhere else. Feature testing would generally be a better idea than version number comparisons though, if you can come up with a reliable feature test for every change that Compat and others need to worry about. Considering how rarely this comes up I don't think there will be much support for being rigorous about adding tag constants though. Post-1.0, maybe. Usually "this would be a good candidate for Compat" isn't immediately apparent.

[vtjnash]

much of the time, feature tests can be accomplished with a simple isdefined(Base, :foo) test. historically, I've had that rejected in favor of a test that is more explicit about the fact that this is a version-dependent change. as a compromise, I usually write my tests as if VERSION > "v0.4-" && isdefined(Base, :foo) so that there is a self-documented expected introduction version + an indication of the exact feature that changed.

[nalimilan]

Maybe Compat could print a very explicit warning on load when version info is not available? (At least until we are able to replace all version checks with isdefined, if at all possible.)

[eschnett]

Compat doesn't work without version information. Why not abort with an error instead?

Also, since Julia doesn't have version information, it should make this explicit in its version string. Silently reporting an incomplete (wrong) version is not a good idea. Maybe Julia could report the version as 0.5.0-dev+unknown?

[tkelman]

Exactly what criteria do you propose using for the abort? Some way of indicating that the precise build number is unknown wouldn't be a bad idea though.

[eschnett]

A version number that ends in dev instead of dev+NUMBER should cause Compat to abort. Technically that probably means that the prerelease part is dev, and the build part is empty?

[tkelman]

#17434 may help alleviate some of your concerns here