<html><head></head><body><div>On Sun, 2017-05-07 at 10:11 -0700, Justin Garrison wrote:</div><blockquote type="cite"><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">I have a collection of python scripts and some external 3rd party executables (puppet) I want to package in a portable way. I'm not sure flatpak is the right solution for this but I wanted to ask. The options I have thought of are</div><div class="gmail_default"><ol style=""><li style=""><font face="tahoma, sans-serif">Docker container</font></li><li style=""><font face="tahoma, sans-serif">Flatpak/snap/appimage</font></li><li style=""><font face="tahoma, sans-serif">Virtualenv/software collections</font></li></ol><div><font face="tahoma, sans-serif">Each package type has pros and cons but I'd like to package this up so the host system needs minimal requirements but the scripts still have full access to the host. My main problems right now is trying to maintain compatibility with different versions of python + libraries, different versions of puppet, and different ways each packaged executable sees the rest of the system (e.g. docker container needs to mount / in a different location).</font></div></div><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><br></div><div><div class="gmail_default" style="font-family:tahoma,sans-serif">Does anyone have experience or documentation for packaging scripts that need system access in flatpak? Would also appreciate if anyone has examples I can look at or more things I should consider with the different formats.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"></div></div></div></div></div></div></blockquote><pre>
</pre><div>This is not really the target usecase for flatpak, but it could very well work. However, it depends a bit on what you mean by full system access. You can easily package the python scripts and libraries in a flatpak, and then grant that app full filesystem and network access. However, it will not be able to see some things. For instance, /usr and /etc will be from the runtime, not the host, and /run, /tmp, /proc etc are specific to the sandboxed instance. /dev is too, but you can grant access to the host dev if you need. It really depends on what you want to do.</div><div><br></div><div>Also, running the scripts will be somewhat painful. Say the app is org.my.Scripts, then you can do something like:</div><div><br></div><pre> flatpak run --command=script1 org.my.Scripts --args-for-script</pre><pre><br></pre><pre>Which is hardly ideal for CLI use. Although some aliases for this could make it easier to use.</pre><div><br></div><pre><br></pre><div><span><pre><pre>-- <br></pre>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl@redhat.com alexander.larsson@gmail.com
He's a sword-wielding one-eyed Green Beret trapped in a world he never
made. She's a sarcastic French-Canadian archaeologist who dreams of
becoming Elvis. They fight crime!
</pre></span></div></body></html>