cryptomator / cli

Cryptomator Command-Line Interface
GNU Affero General Public License v3.0
287 stars 43 forks source link

The official released jar file should be named simply "cryptomator-cli.jar" #38

Closed mhogomchungu closed 3 years ago

mhogomchungu commented 3 years ago

Currently, the released jar file has a name with a format of "cryptomator-cli-$VERSION.jar".

This name format causes the name of cryptomator-cli to changes with every version making it hard for other tools that interface with cryptomator-cli to check if it is installed or not.

I think the name should be simply "cryptomator.jar" and this[1] feature request should be used to figure out what version is installed in user's systems.

[1] https://github.com/cryptomator/cli/issues/37

overheadhunter commented 3 years ago

So why don't you rename it?

mhogomchungu commented 3 years ago

I have a project called SiriKali[1] and people have asked for a cryptomator backend support[2][3] and i have decided to add it for cryptomator-cli when it is using FUSE.

The problem i am facing are:

  1. How does SiriKali figure out if cryptomator-cli is installed when SiriKali is running on $RANDOM_DISTRO.
  2. if this feature request is implemented, then how does SiriKali figure out what version of crytomator-cli is installed.

The two bug reports i have opened asked for these two things.

Any person who will be creating a front end for cryptomator-cli will want to have a consistent name they can rely on.

Look how simple this[4] line is and imagine how it would be if java executable was dependent on its version.

[1] https://mhogomchungu.github.io/sirikali/ [2] https://github.com/mhogomchungu/sirikali/issues/127 [3] https://github.com/mhogomchungu/sirikali/issues/81 [4] https://github.com/cryptomator/cryptomator/blob/e8d17cfb7b41e3eb8fa3e5083d702d8f01f48087/main/buildkit/src/main/resources/launcher-linux.sh#L3

overheadhunter commented 3 years ago

Ok I see, so you don't bundle cryptomator-cli yourself but rely on it already being installed somewhere? So how do you find out where the jar lays around in the first place?

I think what you really need is a binary accessible via PATH, don't you?

mhogomchungu commented 3 years ago

No, i am not bundling any of the supported backends and ideally, users should install them through their distribution's official channel.

What i want is to set the name of the executable like i do here[1] and then search for it at startup in paths specified here[2]. Java executable is added here[3]

[1] https://github.com/mhogomchungu/sirikali/blob/ddead10260c6e3243d813c4cd4b8285bc46356a0/src/engines/cryptomator.cpp#L53

[2] https://github.com/mhogomchungu/sirikali/blob/ddead10260c6e3243d813c4cd4b8285bc46356a0/src/engines.cpp#L76-L92

[3] https://github.com/mhogomchungu/sirikali/blob/ddead10260c6e3243d813c4cd4b8285bc46356a0/src/engines.cpp#L422-L427

overheadhunter commented 3 years ago

Ok in this case it's not the name of the jar created on this repo that needs to be deterministic, but you need a deterministic executable name that is installed on the user's PC.

Currently there is no such executable name, since we don't provide any kind of installer. cryptomator-cli is just a tool for enthusiasts who download it themselves from this GitHub repo and we have no idea where they save it and what name they give it.

mhogomchungu commented 3 years ago

Ok in this case it's not the name of the jar created on this repo that needs to be deterministic, but you need a deterministic executable name that is installed on the user's PC

Yes.

Currently there is no such executable name, since we don't provide any kind of installer. cryptomator-cli is just a tool for enthusiasts who download it themselves from this GitHub repo and we have no idea where they save it and what name they give it.

Users who download it themselves or distributions that packages it will most likely go with the default name chosen by upstream and set in the download page and the name for the latest version is "cryptomator-cli-0.4.0.jar"[1] and what i am asking is for the "-0.4.0" part to be removed when the next version is out to give a consistent name across versions.

Why was it added in the first place? CLI tools usually don't bundle their version string in their names.

[1] https://github.com/cryptomator/cli/releases/tag/0.4.0

mhogomchungu commented 3 years ago

While here, just though i should mention that i just purchased a version for android to support your effort.

Screenshot_20201105_101816

overheadhunter commented 3 years ago

Why was it added in the first place? CLI tools usually don't bundle their version string in their names.

Please don't mix up these two things:

  1. Installed tools don't include the version number in their names. That is for the reasons you mentioned above.
  2. Downloads usually do include the version numbers. Otherwise there is no way to distinguish what you've downloaded.

If there was an installer foo-installer-1.2.3.exe (version included in filename), it'd be its job to install version 1.2.3 of foo to its destination path C:\whatever\foo.exe (same name for all versions)

The jar in question qualifies as neither. It is not even a binary file. Linux FHS would install such a file under /usr/local/share/cryptomator-cli-x.y.z.jar and put an executable into /usr/local/bin/cryptomator-cli (probably a shell script running java -jar).

mhogomchungu commented 3 years ago

The jar in question qualifies as neither. It is not even a binary file. Linux FHS would install such a file under /usr/local/share/cryptomator-cli-x.y.z.jar and put an executable into /usr/local/bin/cryptomator-cli (probably a shell script running java -jar).

I did not know about this and i think it will solve the problem.

mhogomchungu commented 3 years ago

I have decided to start distributing cryptomator-cli and to simply call it "cryptomator-cli.jar".

My fork is here[1] and i also added a few things to make it behave more or less like other FUSE based backends SiriKali supports.

[1] https://github.com/mhogomchungu/cli