DUB should expose a package's version to the respective package

[wilzbach]

Problem: the built program should expose its version to the user (e.g. --version).

Semi-generic workaround:

This will generate a bin/dubhash.txt file that can be imported anywhere in the program with import("dubhash.txt").

  "stringImportPaths": ["bin"],
  "preGenerateCommands": [
    "rdmd --eval='auto dir=environment.get(`DUB_PACKAGE_DIR`); dir.buildPath(`bin`).mkdirRecurse; auto gitVer = (`git -C `~dir~`describe --tags`).executeShell; (gitVer.status == 0 ? gitVer.output : dir.dirName.baseName.findSplitAfter(environment.get(`DUB_ROOT_PACKAGE`)~`-`)[1]).ifThrown(`0.0.0`).toFile(dir.buildPath(`bin`, `dubhash.txt`));'",
  ]

This workaround will default to git describe --tags (within the packages's directory) and if that fails it will detect its version based on the DUB package path.If that fails too, it will fallback to 0.0.0.

The workaround "works", but obviously it would be nicer if dub found a standardized way to expose the package's current version to the package itself. It has this information after all...

[WebFreak001]

yes pls add enum PackageCommitSha = "..."; and enum PackageVersionTag = "v0.1.0"; and the same for subpackages using enum Package_<id>_CommitSha and Package_<id>_VersionTag, dub already knows about these and I just needed that in serve-d but instead used the github api to get commit date and built with __TIMESTAMP__ to find out if a program is outdated

[andre2007]

Does this PR somehow helps you?
Environment variable DUB_PACKAGE_VERSION added (#1562)

[WebFreak001]

I don't think that is helpful as it's just for the commands dub can run. What would fix this issue imo would be having defines (enums) set to the versions.

[wilzbach]

Does this PR somehow helps you?

It simplifies the logic quite a bit - though it's probably such a common use case that we won't it to be possible without the need for any custom D code?

[andre2007]

I fully agree. I have a similar logic in all of my productive applications.

I have 2 things I want to mention.

• I know the version attribute in dub.json is not officially supported but could the solution respects this value if set? (By using Package.version_ attribute).
• if the solution is a dub hash file could the generation be switched on/off on per dub configuration? Also it would be good if the user can influence the file path.

As explanation: the build pipeline i have to use (XMake based) doesn't allow git tags created by developer but creates itself git tags. On the other side the build pipeline want to know the dub project version. The unofficial dub.json version attribute works like a charms here.

[Herringway]

I think a dub-generated D module containing dub describe's output (preferably in a more D-friendly format, though JSON is at least workable) would be able to accomplish this and more

[Geod24]

Just noticed that this is one of the oldest issues we still had open: #6 !

[Geod24]

Another use case: #437