organisation
organisation copied to clipboard
apertium
"easter egg" for showing language pair version
It'd be nice to be able to do something like
$ echo AP_PAIR_VERSION | apertium foo-bar
74a6bc782f95c94ebfd8238063e256df40e84bb8
where 74a6bc782f95c94ebfd8238063e256df40e84bb8 is the git commit of the language pair foo-bar.
This is easy by just adding
<e r="LR"><p><l>AP_PAIR_VERSION<s n="adv"/></l><r>74a6bc7…<s n="adv"/></r></p></e>
<e r="RL"><p><l>74a6bc7…<s n="adv"/></l><r>AP_PAIR_VERSION<s n="adv"/></r></p></e>
into bidix before compilation (so it'll come out as #74a6bc782f95c94ebfd8238063e256df40e84bb8 but that's fine?), but it has to be automatic somehow (an xslt right before lt-comp?).
Caveat: Packages have no knowledge of git commit or any other versioning information, beyond what I pass in. The builders don't have network access nor even git installed. So any such easter egg must take that into consideration - easter egg information may be null.
And it must not be a timestamp, because it must be a reproducible build.
Asides from those caveats, good idea.
https://github.com/apertium/apertium-packaging/blob/master/make-deb-source.pl can inject the version, if space has been provided for it. I suggest placeholder APERTIUM_AUTO_VERSION (GITREV is too generic).
How should this behave with split languages? It'd be nice if a pair has AP_PAIR_VERSION for the combined, but also AP_LANG_VERSION for each direction separately. And if that's not possible, then it should be AP_SOURCE_VERSION to be generic.
Yeah, was wondering if the individual languages shouldn't have that too. That should be easy as well.
nno-nob has AP_PAIR_VERSION and nno/nob have AP_LANG_VERSION with @APERTIUM_AUTO_VERSION@ now.
"The builders don't have network access nor even git installed." How do you get the data on and off them? @TinoDidriksen
"The builders don't have network access nor even git installed." How do you get the data on and off them?
The controller prepares all the data and passes it off to a restricted offline Docker container that mounts the host build folder. That way the part that runs as root never gets to run user-provided code.
Oh, okay. What would be involved in passing in a git commit id?
That part is already done. It was implemented a year ago in https://github.com/apertium/apertium-packaging/commit/630cf3a553e391198c8083e79bc2fec6632f07c8
This issue is kept open because not all languages and pairs have these entries yet. The respective placeholders need to be added to everything, and apertium-init.
Alternatively, make-deb-source.pl needs to inject all the information during tarball generation. That's harder, but doable.
Oh okay that makes sense.
On Sat, Jun 6, 2020, 12:10 Tino Didriksen [email protected] wrote:
Oh, okay. What would be involved in passing in a git commit id?
That part is already done. It was implemented a year ago in apertium/apertium-packaging@630cf3a https://github.com/apertium/apertium-packaging/commit/630cf3a553e391198c8083e79bc2fec6632f07c8
This issue is kept open because not all languages and pairs have these entries yet. The respective placeholders need to be added to everything, and apertium-init.
Alternatively, make-deb-source.pl needs to inject all the information during tarball generation. That's harder, but doable.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/apertium/organisation/issues/10#issuecomment-640105271, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN54XPZUIE6AF5UR27QIN5TRVKICZANCNFSM4HU766XA .