Nikola is a static site generator. With strict confinment it works, but it has some limited capabilities:
You can’t install plugins because of confinement rules. I think this may be possible to workaround, but it’s never going to be smooth.
You can’t use some options. Specially, when you want to see the preview of the site, there is a -b option to open it in a browser without having to copy/paste URLs. That doesn’t work (could be worked around using snapd-xdg-open)
You can’t run “nikola deploy” because it calls arbitrary commands
You can’t use some tools like less/sass/minifiers because they are external
So, basically, it works, but in a rather painful way.
In my opinion, this is the same case we have with errbot.
The snap for errbot has a limited use, it’s mostly a demo for basic capabilities. It works for very simple cases, but as things get complicated, you want to install more python packages and everything gets messy. When you have something more complicated, you don’t install the errbot snap, you use it as a building block for your own snap, like I explained in my blog post.
The same with nikola, instead of using the snap to develop a complex site, I would make a snap for my complex site with nikola as a part.
The problem is thinking that the snap is good for development. It is good for deployment. If you want to develop something with python, I think a virtualenv is better than a snap. But well, that’s my opinion because I dislike classic snaps very much.
People from the security team and snap advocacy might agree with you that nikola should be classic. I’m just commenting here where nobody asked for my opinion because I love nikola, at last I found something that makes me enjoy maintaining my blog. Thanks for working on that.
I don’t mind nikola being classic, given that it is python I even prefer a snap as the snap will be working, this is the reason I switched from nikola to hugo a long time ago. Keeping up with nikola in my virtualenv wasn’t fun.
As noted in Process for reviewing classic confinement snaps, the request for classic is less about the security team being happy and more about capturing why the snap needs classic (so snapd developers can potentially improve snapd) and establishing trust in the publisher of the snap (since classic snaps provide root on all devices where the snap is installed). This is something that @evan and the advocacy team will lead with other store reviewers commenting on as appropriate.
Thanks for your input! I think participating in requests like this is really helpful.
As a nikola user, I’m keen to make sure it ‘just works’. I am concerned when we go for classic as a brute force way to get things working as I’d way rather we looked at the individual issues and work them through. Partly because it’s more secure as non-classic, but partly because currently classic snaps don’t work on all distros. So being a classic snap means you cannot be installed on (for example) Fedora as a snap.
For 1) Can the plugins not be placed in $SNAP_USER_DATA somewhere?
2) I understand work is ongoing to integrate the snap-xdg-open component in snapd itself, so this could be solved for you, if you call xdg-open inside nikola
3) Isn’t there a very limited set of commands this is likely to be? rsync, scp, cp, mv? Can (at least those) be staged in the snap?
4) The snap-way is to bundle in what’s needed, how much additional overhead do we have if you bundle in the necessary tools/utilities?
The plugins can be anywhere. Usually they live in the plugins/ folder of the site so that should not be a problem. But plugins often bring up python dependencies.
For example, a plugin to use commonmark will require the commonmark python package. I can’t install it in the snap, since it’s readonly. So, no idea how to handle this. Should I ship pip? Add something to PYTHONPATH and install there?
It uses python’s webbrowser module. How that works under the hood, I don’t know.
I don’t know.
I don’t know. Literally, anything can be used this way.
In any case, I am happy to keep pushing a semi-functional snap as it currently exists. I stopped supporting usage of the debian package because it was never updated, and as mentioned running from source is not exactly trivial at times.
So, if this doesn’t fix the issues I guess I have options:
Stop caring about it, users use sources.
Look for other ways to get this to work that are not snaps.
Sadly, time I can spend on this is basically no time at all. Feel free to close the issue if classic is not the right solution.
Trick there is that you don’t update Nikola at all unless you actually need/want to. I have sites that have Nikola from 3 years ago and are still building just fine.
@ralsina Are you the maintainer of the snap, and do you have a working classic snap (or is willing to work on one) that would be significantly more usable as described in the top message? If so, +1 on making it classic for the time being. We can always bring it back to strict once the main issues are sorted.
Fedora can also use the classic snap easily if the /snap link is added.
