AppImageAsistant should not require pygtk2 and libpng12 when run in CLI about appimagekit HOT 6 CLOSED

Is pygtk2 needed also in the experimental branch, when not using the GUI?

from appimagekit.

i'm still fighting to compile experiemental

from appimagekit.

6ac5788 closes this. Actually this had been working before it was broken by 364f271

from appimagekit.

Ok, the problem was then that 364f271 deliberately removed support for running the application with just three arguments in order to pack, when adding the --pack and --unpack commands, because it was ambiguous, so you weren't actually running in CLI mode.

If the old behavior needs to be respected, it could've been added after the loop that checks for --pack, --unpack, etc.

Also please bear in mind that
os.system(os.path.dirname(__file__) + "/package %s %s" % (sys.argv[1], sys.argv[2]))
instead of
os.system(os.path.dirname(__file__) + "/package '%s' '%s'" % (sys.argv[1], sys.argv[2]))
will not respect spaces in filenames

from appimagekit.

What do you mean by "it was ambiguous, so you weren't actually running in CLI mode"?

Personally, I prefer cp a b over cp --from a --to b ;-)

Changing the syntax broke build scripts which depended on it.

from appimagekit.

My bad, I should've discussed before happily changing the paradigm of the tool operation:

• cp a b works well for cp, because that's the only thing cp does: copying
• Package format managers like tar, zip, 7z, etc, on the other hand, need to specify a command in every invocation, usually pack, unpack, and test/list.

I understand AppImageAssistant to be in the same group as tar, zip and 7z: one single tool to operate with AppImages. It is true that AppImageAssistant is different, in the sense that if run without arguments it will pop up a nice UI to make it compatible with doube-clickers, and specially in the sense that the pack command is more important here than the unpack command because there's usually no need for the user to unpack an AppImage (compared to the other tools, where packing is just as important as unpacking), but I still think further operations with AppImages should be allowed, even if we let the pack command to be the protagonist, allowing it to be run without explicitly declaring --pack.

What do you mean by "it was ambiguous, so you weren't actually running in CLI mode"?

it was ambiguous

I meant that no command was specified, although now I think it'd be fine to keep this behavior in this case, being the pack operation more important than any other operation for AppImages

so you weren't actually running in CLI mode

My patch implied that you'd run in CLI mode only if an explicit --pack, --unpack or --help command was specified, so if you just specified your three arguments without command, the tool would just ignore the arguments, start the GUI, and fail when trying to load Gtk.

from appimagekit.