Automatically set and use $VERSION

[probonopd]

Automatically set and use $VERSION.

• If the main application comes from Conda, use that version
• If the main application comes from PyPI (pip), use that version
• If the main application comes from git, use git rev-parse --short HEAD

[TheAssassin]

Define "main application". There is no such concept in this tool.

Git hashes are IMO not a version scheme. Old versions may show up above newer versions etc...

[probonopd]

The application which is referenced in the desktop file, and is executed when AppRun runs.

If it can't be done automatically, then how can it be done by hand? E.g., the TruFont script, when running, uses git so I assume it should be possible to get the git rev-parse --short HEAD somehwere. But I don't know where to hook in. After linuxdeploy-plugin-conda is done it's too late.

[TheAssassin]

Anything like that is out of scope of the plugin, as it's handled on a higher level.

Just export VERSION as you like in your script. You can just set the var above all linuxdeploy stuff, and inherit it in your PIP_REQUIREMENTS or wherever you like:

export VERSION=1.2.3
export PIP_REQUIREMENTS="myapp==$VERSION"
./linuxdeploy-x86_64.AppImage ... --plugin conda ...

[probonopd]

How can I know the git string before git has even started working?

[TheAssassin]

What "git string"? Why should git have anything to do with this? Who even wants git hashes as versioning scheme?

[probonopd]

My TruFont script currently produces TruFont-x86_64.AppImage. But I want it to produce TruFont-09c640d-x86_64.AppImage, like we do for practically all continuous AppImages. git which is running as part of the process can figure out the string 09c640d; I can't know it in advance.

[TheAssassin]

I don't do any of this sort of versioning any more, for the reasons stated here. Either do proper versioning, or combine the commit hash with a date to ensure proper sorting, or anything. The pure git hash is annoying.

I have no clue where git would be running in the process. If it's run by pip directly: you got no access to the repo, as it's used internally only, and not exposed. Also, most Python packages that can also be installed from a git source have some real version numbers in them anyway.

In general, it's not recommendable to install stuff from git directly (especially from dev branches), rather install stuff from PyPI etc.

There is no way for a plugin like this to know "okay I'm installing the main app" or "I'm setting up a Python interpreter which will be used by another tool, e.g., for scripting".

[probonopd]

export VERSION=$(wget -q "https://api.github.com/repos/trufont/trufont/commits?sha=master" -O - | grep sha | head -n 1 | cut -d '"' -f 4 | head -c 7 )

will have to do then.

Is there a way to make

export PIP_REQUIREMENTS="-e git+https://github.com/trufont/trufont#egg=$APPNAME fs" request the hash that is in $VERSION?

[TheAssassin]

No, it'll use the latest version available. I am not sure how to request a specific tag this way. Please see https://pip.pypa.io/en/stable/reference/pip_install/#git.

[c02y]

Not linuxdeploy-plugin-conda just linuxdeploy appimage here, why linuxdeploy will use git to get the hash id even thought I already set VERSION in app.desktop, if the version is not set in app.desktop, it use git I'm OK with it, if I provide VERSION, it should use the VERSION I set.

export VERSION=1.2.3
./linuxdeploy.appimage ...

will use the VERSION, but this is just a workaround.

[TheAssassin]

why linuxdeploy will use git to get the hash id even thought I already set VERSION in app.desktop

First of all, it's not linuxdeploy, it's appimagetool that enforces this git hash stuff. The key in a desktop file is not VERSION but X-AppImage-Version, and I'm really sure appimagetool would not preserve an existing value.

[probonopd]

it's appimagetool that enforces this git hash stuff.

iirc all that appimagetool enforces is that some $VERSION is set, am I wrong?