Added support for bundling in auxilliary files

[dotzborro]

Hi, My intentions with this PR are to spur discussion whether it would make sense. Then, if we come to agreement, I can move it forward.

In a nutshell, what we need in order to use python-appimage is a way to bundle auxiliary files that can be then accessed by script invoked by entrypoint. These files are Docker images, thus quite big, and cannot be included in any other way.

The change from this PR is enough to make it work - just create files/ in the App dir and it will then be available to the script. However, I'm not sure if such implementation is good enough:

• I'm not sure about naming: is files/ okay?
• I'm not sure if this shouldn't be configurable - e.g. some conf file specifies where auxiliary files are stores
• does our reasoning make sense at all and is it okay to put such functionality :wink:

Please let me know what do you think about it. Then, I guess it would be necessary to include some info in the docs etc. I can take care of this.

[niess]

Hello @dotzborro,

this functionality would make sense to me. I mean, one could of course extract the AppImage, manually copy the data to the extracted AppDir, and then rebuild the AppImage. But, your proposal would be more effective and simple.

Just, I would not bundle data by default. Instead, I would rather add a command line option for speciying directories or files to packaged. Thus, by default no extra files would be packaged. My point is that a user might have added a files directory to his application folder -for personal usage- that would then be erroneously packaged in the application. This is unlikely but still possible. Therefore, I would rather have users explicitly specify files to be packaged (from the command line for example).

Would this work for your use case?

[dotzborro]

Definitely it would work. I was thinking of parameter that can be passed multiple times to include several "overlays" but in the end I guess it would be better if we offload overlaying to the user and let the python-appimage just copy provided FS tree in single step.

I'm going to push commits that go in the direction you described and I'll also change the docs to indicate this new possibility.

In the meantime

• would appreciate if you gave your input here as well https://github.com/niess/python-appimage/issues/75
• I find it scary that there are no tests here. Yesterday I set up tox&pytest, but writing first test requires some work. Please let me know what do you think. Should you find it unnecessary please let me know :smile:

[niess]

@dotzborro,

concerning your second point, "tests", I agree. Currently, I am doing this manually (e.g. by checking that some base Python images and example applications are properly built). But, am not very confident with that neither.

The main reason for not having automated tests is the time required for setting this up. I must say that python-appimage is a side project for me. For my work (I am a Physicist), I actually only use the base Python AppImages (e.g. for deploying a specific Python runtime on a computing center).

If you have the time to set up automated tests, that would be very welcome. However, it might be complicateddue to the fact that python-appimage was designed as an executable, not as a library. Note also that python-appimage is expected to work down to Python 2.7.

[dotzborro]

@niess thanks for the hints. By supporting Python 2.7 you mean building for target Python 2.7, or building on machine, where there's Python 2.7? Regardless, could you please share the commands you're using to test it?

[niess]

Hello @dotzborro,

in short, both.

The python-appimage package should work from a Python 2.7 runtime (regardless of the produced AppImage Python version, down to 2.7), and for producing a Python 2.7 AppImage (regardless of the Python runtime version, down to 2.7).

Examples of test commands can be found in Github Actions (e.g. here and there). However, note that Python 2.7 is no more supported by the setup-python action :(

[niess]

Hello @dotzborro,

just to be sure, is this updated PR ready to be merged on your side? It looks so to me.

[dotzborro]

@niess uh sorry for no updates. For sure I didn't forget about it, I just happen to have lot of private stuff going on and also quite a busy time at work.

I uploaded my most recent changes so they don't rot on my computer. I was trying to setup a machine with Vagrant to test it out with python2 on Arch linux, but it proved to be cumbersome, effectively leading me to postpone it. Recently I thought that if we already have GH actions, maybe there is a way to just run them locally and confirm nothing's broken.

If the changes are looking good, I don't have objections to pull it in. The environment I need to setup won't escape me anyway.

For my work (I am a Physicist)

Great! What do you do? I'm asking just out of curiosity and if you're not comfortable with providing answer here just don't :smile: My personal interest in Physics is growing recently, but unfortunately I only have time to watch YT (e.g. PBS Space Time, Sabine Hossenfelder etc).

[dotzborro]

Ah, one more thing - we should document this behavior at least. But we can do it in separate PR.

[niess]

Hello @dotzborro ,

I slightly changed the syntax, allowing for multiple data (being a directory or a file), and I finally merged. In order to get back the initial behaviour, the syntax would now be

-x directory/*

instead of

-x directory

Hopefully, I did not introduce a bug doing so (I tested locally).

Concerning my work, I am a particle physicist, on the experimental side. But, nowadays I am working on more applied topics (though, I am still hunting cosmic neutrinos, here and there).

[dotzborro]

@niess I checked your change. LGTM

Concerning my work, I am a particle physicist

The barman says: “We don’t serve faster-than-light particles here.” A tachyon enters a bar.