search

AppImage / appimagetool

A low-level tool to generate an AppImage from an existing AppDir
58 stars 11 forks source link

Add APPIMAGETOOL_APP_NAME environment variable #18

Closed TheAssassin closed 12 months ago

TheAssassin commented 1 year ago

Allows using the output name generation appimagetool provides with desktop files whose Name entry is unsuitable for the purpose. Users can specify their own prefix with this new environment variable.

Based on #17, please do not merge but only approve if it works for you. You can find the diff to the other branch here: https://github.com/AppImage/appimagetool/compare/document-env-vars...app-name-prefix?expand=1

TheAssassin commented 12 months ago

it works as designed

Nobody ever questioned that.

I can only see downsides in this - AppImage files with names different from how the application actually is named.

There is no logic in this argument. There already is an output path parameter that does exactly this.

I consider it a feature that the Name= entry is used for naming the AppImage file, because only this way the two can guaranteed to be always consistent. The AppImage file should be named like the application is named, in the same spelling, capitalization etc. (just blanks replaced by _).

Still there as a fallback.

There should be only one "source of truth" for the name of the application. Don't like it? Change the Name= in the desktop file.

That again doesn't make a lot of sense.

The rationale for this change is tools like appimagecraft or KDE craft which need to have predictable output. They usually know the application name, and want a unified name pattern on all platforms. It makes no sense to have an AppImage called My_Fantastic_Application-v1.2.3-x86_64.AppImage, whereas the Windows installer is called my-fantastic-application-v1.2.3.exe and the macOS binary is named similarly.

The reason why the output name parameter is not used (or rather useless) is that the automatic generation of a suitable name is actually pretty useful. Having appimagetool guess the architecture (which typically works quite well) and insert the version number in a standardized way is a good thing.

People should really be able to use this feature with a customized name and should never have to reproduce the name generation appimagetool already provides yet again. It makes no sense.

TheAssassin commented 12 months ago

Also, having to actively rename the file makes no sense, just because the tool is limited in this way...

TheAssassin commented 12 months ago

complexity

Have you actually seen the change? It doesn't add any significant complexity while fixing some potential stack overflows even...

probonopd commented 12 months ago

The rationale for this change is tools like appimagecraft or KDE craft which need to have predictable output. They usually know the application name, and want a unified name pattern on all platforms. It makes no sense to have an AppImage called My_Fantastic_Application-v1.2.3-x86_64.AppImage, whereas the Windows installer is called my-fantastic-application-v1.2.3.exe and the macOS binary is named similarly.

And that is exactly my point. If the application is called "My Fantastic Application", then traditionally you have

But hey. If KDE Craft needs it, then well.

Also, having to actively rename the file makes no sense, just because the tool is limited in this way...

Renaming the files is a big no-no in any case, because it breaks AppImageUpdate.

TheAssassin commented 12 months ago

More use cases:

Software, especially cross-platform and/or commercial, need such features.

TheAssassin commented 12 months ago

because it breaks AppImageUpdate

I disagree. This only happens in some use cases. For instance, many projects generate their own .zsync files. Being able to do so from appimagetool is just a convenience feature. Also, these files can be patched yet again.

You really should see some of the deployment pipelines I came across in the last years...

probonopd commented 12 months ago

https://github.com/pop-os/popsicle usually uses "USB Flasher" as a Name

Bad, bad, bad.

https://github.com/pop-os/popsicle calls it "Popsicle" in the README.md. That is the name of the product. So it should be Name=Popsicle, GenericName=USB Flasher, and Popsicle-0.0.0-x86_64.AppImage.

Maybe I am so picky about this because part of my dayjob is to enforce unified spelling of product names all the time.

But again, my thoughts here are not a hard veto. Just food for thought.

TheAssassin commented 12 months ago

So what? It's the UX they chose. On their own desktop, this is perfectly fine (GNOME for instance just uses "Software" instead of "GNOME Software", "Files" instead of "Nautilus", etc., which works on such a desktop and of course is confusing outside of it). But I think this is not the place to discuss such things. I just want to show that these use cases exist and appimagetool could be more helpful.

TheAssassin commented 12 months ago

not a hard veto

Well, you blocked merging with your changes request. Please approve the changes then.

probonopd commented 12 months ago

You want to make it easy for them to continue that mess whereas I want to "forcefully remind" them to end the mess. ;-)

If you want to do me a favor, let's state in the documentation for this environment variable that it is best practice to use the exact same name, spelling, and upper/lowercase for: