package as a snap/flatpak package?

[jawz101]

I was wondering if PyFunceble could be packaged as a snap package or flatpak. I'm not a python update expert and it looks like the documentation shows 3 ways to install and 3 ways to update depending on the python, pip or github way you do it. I just got a message that I needed to update my PyFunceble to a new version and I don't remember how I installed it in the 1st place :/

I hate to propose yet another way to implement it but if it was an isolated installation it could be packaged with its dependencies, its environment would be self-contained- regardless of Linux flavor, and updating would be as simple as "sudo snap refresh" which finds updates for any snaps that need updating.

Just a thought :)

[funilrys]

Hi @jawz101 and welcome here!

A simple which PyFunceble may reveal the location of your executable which may help us help you know where and how you install it!

Will think about your thought and will inform you if it's possible or not!

Have a nice day/night and thanks for this issue!

[funilrys]

Back to this @jawz101,

I tried snap but under Arch Linux I get Unable to determine host OS version codename when trying to test following their documentation. Will dig into that later.

Let's see about flatpak now 😸

[jawz101]

@popey might be able to help with snap packaging. Sorry, Mr. Pope. You don't know me but I'm a huge fan of Ubuntu podcast & LUP.

[popey]

Would you accept a pull request with a snapcraft.yaml? :)

alan@hal:~/Source/pyfunceble$ snapcraft 
Device /root/build_pyfunceble removed from snapcraft-pyfunceble
Waiting for a network connection...
Network connection established
error: no changes of type "auto-refresh" found
snap "core" has no updates available
snap "snapcraft" has no updates available
Mounting /home/alan/Source/pyfunceble into container
Device /root/build_pyfunceble added to snapcraft-pyfunceble
Skipping pull pyfunceble (already ran)
Skipping build pyfunceble (already ran)
Skipping stage pyfunceble (already ran)
Skipping prime pyfunceble (already ran)
The requested action has already been taken. Consider
specifying parts, or clean the steps you want to run again.
Stopping local:snapcraft-pyfunceble
Snapping 'pyfunceble' -                                                                                                                                                        
Snapped pyfunceble_0.94.3-beta_amd64.snap

alan@hal:~/Source/pyfunceble$ snap install pyfunceble_0.94.3-beta_amd64.snap --dangerous
pyfunceble 0.94.3-beta installed

alan@hal:~/Source/pyfunceble$ pyfunceble

██████╗ ██╗   ██╗███████╗██╗   ██╗███╗   ██╗ ██████╗███████╗██████╗ ██╗     ███████╗
██╔══██╗╚██╗ ██╔╝██╔════╝██║   ██║████╗  ██║██╔════╝██╔════╝██╔══██╗██║     ██╔════╝
██████╔╝ ╚████╔╝ █████╗  ██║   ██║██╔██╗ ██║██║     █████╗  ██████╔╝██║     █████╗
██╔═══╝   ╚██╔╝  ██╔══╝  ██║   ██║██║╚██╗██║██║     ██╔══╝  ██╔══██╗██║     ██╔══╝
██║        ██║   ██║     ╚██████╔╝██║ ╚████║╚██████╗███████╗██████╔╝███████╗███████╗
╚═╝        ╚═╝   ╚═╝      ╚═════╝ ╚═╝  ╚═══╝ ╚═════╝╚══════╝╚═════╝ ╚══════╝╚══════╝

Nothing to test.

[funilrys]

@jawz101 @popey Pull requests are always open but keep in mind that we are working in the dev branch first as the master is only for release of new version/features designed.

Also:

• What is the difference between snapcraft.yaml and pyfunceble_0.94.3-beta_amd64.snap in your snippet ?
• Why do you use the --dangerous flag ?
• Is there a way we can automate the process along with our commits ?
  • Indeed actually when I push under the dev branch I also (with the help of a script in my dev environnement) publish it to PyPi and AUR so that I can get feed back from the @dead-hosts or @Ultimate-Hosts-Blacklist infrastructures and my test machine (which runs with Arch too, sorry @jawz101 😉).
• Is providing the snap/snapcraft.yaml suffisant for snap users or should I also submit it to snapcraft.io ?
• Is snap designed to handle a high level of update ?
  • Indeed if I add it to my automated process, somedays I push a lot in the dev branch which create instantly a lot of new dev version.

[popey]

Thanks for the quick reply. What I made was just a quick prototype I made when I got the ping, and may not fully work (sorry, I'd not heard of your project before the ping, but I'm sure it's awesome) :D. So it would be good to have some test cases and expected outcomes so I could work out any kinks before committing.

What is the difference between snapcraft.yaml and pyfunceble_0.94.3-beta_amd64.snap in your snippet ?

snapcraft is a tool used to build snaps. snapcraft.yaml is the configuration snapcraft reads to build the snap. pyfunceble_0.94.3-beta_amd64.snap is the resulting snap it built, which is a compressed squashfs file containing your application and necessary libraries.

Why do you use the --dangerous flag ?

Snaps are designed to be installed from the snap store where they're cryptographically signed by the store and go through some checks. If you have a snap which didn't go through the store review process then you can't be confident it isn't dangerous (contains malware) so the --dangerous is just acceptance of that risk. As I built the snap, I am confident it's fine.

Is there a way we can automate the process along with our commits ?

Yes. You could use travis-ci or circle-ci to automate building on each commit. As an example, look at the offlineimap (another python app) travis config in our snapcrafters repo. Whenever someone commits there, it builds a snap for testing before we land it. We also provide a free build service which builds on each commit to the default branch.

Indeed actually when I push under the dev branch I also (with the help of a script in my dev environment) publish it to PyPi and AUR so that I can get feed back from the @dead-hosts or @Ultimate-Hosts-Blacklist infrastructures and my test machine (which runs with Arch too, sorry @jawz101 wink).

I also do some automation locally when building some snaps. snapcraft sadly doesn't work for building snaps on Arch directly. However it will run fine in an Ubuntu VM or container. Personally, I use a lxc container running Ubuntu 16.04 to build things if I want it built clean, or use one of the natty automated ways outlined in the paragraph above.

Is providing the snap/snapcraft.yaml suffisant for snap users or should I also submit it to snapcraft.io ?

Ideally, you would land a snap/snapcraft.yaml, sign up to the store, register the name of your snap, and set the metadata. Once done, you can either manually build and snapcraft push pyfunceble_0.94.3-beta_amd64.snap --release edge to put a snap in the edge channel for testing. Once tested, you can hook up automated builds as above to push to the edge channel, and when you do stable releases, push to the stable channel (there's also optional beta and candidate channels).

Is snap designed to handle a high level of update ?

Yes. Every commit could result in a build in the store which we call a revision. There are numerous snaps which have thousands of revisions uploaded. You control when you upload. You can upload multiple times a day or once a month, that's your choice.

[funilrys]

@popey following may help you test it basically.

But if you need a more deep test, you should test a file containing a list of domains. There are some in our .travis directory.

If you run

PyFunceble -ex -d github.com  && PyFunceble -ex -f .travis/list_to_test && PyFunceble -ex --adblock -f .travis/adblock_to_test

you should get the same as our CI test result (dev branch) or CI test result (stable branch).

---

snapcraft is a tool used to build snaps. snapcraft.yaml is the configuration snapcraft reads to build the snap. pyfunceble_0.94.3-beta_amd64.snap is the resulting snap it built, which is a compressed squashfs file containing your application and necessary libraries.

Okay so that means that we can only deliver the snapcraft.yaml interesting.

Snaps are designed to be installed from the snap store where they're cryptographically signed by the store and go through some checks. If you have a snap which didn't go through the store review process then you can't be confident it isn't dangerous (contains malware) so the --dangerous is just acceptance of that risk. As I built the snap, I am confident it's fine.

So it's more convenient to submit to the store.
Does that means that we can provide a .snap file along with the releases and let the end-user execute/install it without any issue? 🤔

Yes. You could use travis-ci or circle-ci to automate building on each commit. As an example, look at the offlineimap (another python app) travis config in our snapcrafters repo. Whenever someone commits there, it builds a snap for testing before we land it. We also provide a free build service which builds on each commit to the default branch.

So to resume we can update our snapcraft.yaml along with our actual CI tests. And at the other side, https://build.snapcraft.io/ let us build and distribute the package on the store at each commit. Is that right ? It's awesome.
But my question: We have 2 versions the stable (The one you used for your prototype) and the dev version aka pyfunceble-dev on PyPi which is actually our dev branch. Is it possible to build them 2 with the https://build.snapcraft.io/ mechanism?

Ideally, you would land a snap/snapcraft.yaml, sign up to the store, register the name of your snap, and set the metadata. Once done, you can either manually build and snapcraft push pyfunceble_0.94.3-beta_amd64.snap --release edge to put a snap in the edge channel for testing. Once tested, you can hook up automated builds as above to push to the edge channel, and when you do stable releases, push to the stable channel (there's also optional beta and candidate channels).

I think this answer my previous question but does that means that the channel let us play with git branches?

Yes. Every commit could result in a build in the store which we call a revision. There are numerous snaps which have thousands of revisions uploaded. You control when you upload. You can upload multiple times a day or once a month, that's your choice.

That's great 👍