Request for classic confinement: Nift

I just added in some really powerful functionality to Nift which I’m pretty sure wont work through Snap without being granted classic confinement.

Two things I’ve added in are:

  • support for pre-post build/serve scripts, so users can provide scripts to be run before or after building/serving their website;
  • added @script, @scriptoutput, @system and @systemoutput syntax to the template language so that users can run scripts/system commands and inject the output of scripts/system commands when building webpages

This is useful for things like:

  • injecting content from a url when building using cURL (currently doesn’t work through Snap)
  • integrating with things like SASS, Grunt, Live Server/Reload (hot/live reloading) and all sorts of other programs, not all of which will be known before the user tries to integrate with them which requires classic confinement, plus packaging all those things when they aren’t needed would be a HUGE turnoff;
  • integrating with databases and any scripting language the user wants (can’t package Nift with all scripting languages, that would be inefficient and make it ridiculously large)

Despite having a low install count currently, I think Nift is worth Snap having in their store. It’s three times faster than the previous world’s fastest website generator, compact (source code is under 150kb in size and can be compiled in to an executable under 300kb in size, about 24mb with Snap as it comes packaged with Git), integrates with basically any framework, has a growing variety of ready made templates available (and it’s easy to take existing websites and turn them in to Nift templates), along with all sorts of other selling points you can read on the homepage of https://nift.cc

With the exception of the scripting languages, I don’t think there is anything that strictly requires classic. Much of the integration seems to be via the network interfaces (eg, db integration) or strategic use of the content interface for adding functionality.

How are scripting languages expected to be used? Do people use the languages to drive nift or does nift somehow use the languages itself? If the former, I wouldn’t think you would need to ship the languages yourself.

While you provided quite a few examples in your request, for reviewers that don’t know how nift works, can you provide a representative workflow for each bullet point that demonstrates why the snap needs classic?

I have read the webpages about classic confinement but am still a little bit confused about whether that’s what I even want here sorry.

A lot of integration will also happen with system calls to integrate with APIs for example, it’s not really feasible to ship all apis with Nift, nor is it really feasible to ship every possible scripting language the user may want to use, especially when they may only need to use one or a few of them.

Nift can work fine without the scripts, but users can run scripts to do stuff before and/or after building/serving the website for example, or at any point when building pages. They can also input the output of running a script or a system call at any point when building a webpage.

For example when injecting content from a url using cURL you might have @systemoutput(“curl -sS url”) somewhere in the template/content files for your website, so when the page builder comes to process that it will attempt to run the system call “curl -sS url” and inject the output of that at that point in the build process. In order for this to work, Nift needs to be able to call cURL, which it currently can’t do and I’m pretty sure classic confinement would fix. Is it even the same program for windows vs. unix if one was to ship curl with Nift?

To integrate with Live Server I use npm to install live server, then add starting live-server to a pre-serve script so that when nsm serve is called the pre serve script is run which starts live-server. In order for this to work I am pretty sure Nift will need classic confinement. It’s also similar for how Nift integrates with SASS, Grunt, etc…

To integrate with a scripting language users can put @scriptoutput(script-path) anywhere in their template/content files and when the page builder gets to that point of building a web page it will run the script and inject the output of the script at that point in the build process. Both for the scripting language to work and for you to be able to call external programs etc. within the scripts I am pretty sure Nift will need classic confinement?

Please forgive me if I’m completely mistaken about what classic confinement does and is for.

Nift clearly requires the ability to execute arbitrary binaries and falls into the system agent category. +1 for classic confinement.

1 Like

+1 from me too for classic confinement for nift

1 Like

This has received the required number of votes for classic - @advocacy can you please perform publisher vetting?

How does publisher vetting work? Wondering if I’ve missed any messages somewhere?

@advocacy - ping - can you please perform the required vetting?

@reviewers - please note that classic requests do not require votes. What is needed is a clear understanding of the requirements and whether or not those requirements fit within existing use patterns, aka categories. IME, it is clear that this needs classic, though it doesn’t sound like it fits within the ‘system agent category’ (which thus far we’ve limited to cloud agents and explicitly not system management agents), unless I misunderstand what nift does. If something falls without an established category, then we should ask an architect to get involved. We need to enumerate the existing use patterns in the forum (there is an internal trello card to do this).

@n-ham - does nift run any services? If so, what inputs do the services take? My (mis?)understanding was that nift does not have services or agents and instead it is used by web developers to drive website creation. The difference being, does the developer drive the nift process to build a website and push those pages (whether it is static html or dynamic php doesn’t matter) or does the developer use nift to drive a management agent on a fleet of devices/cloud instances/etc?

@jdstrand I’m not 100% clear on what you mean by running any services sorry.

Nift is basically a build tool for making websites (including a page builder/parser). It’s a lot like static site generators (eg. Jekyll, Hugo, Gatsby, Hexo, Nuxt, GitBoot, VuePress, 11ty, etc.) though can also be used for dynamic websites.

The original functionality with Nift was to just compile lots of different files in to web pages, so that you can for example just have the code for your head/header/menu/footer/etc. all in one convenient file. Along with incremental/build-updated functionality so you can just build the updated portions of the website, very useful for speed of development and for things like displaying when a page was last edited/built.

However there’s a bit of a revolution going on with web development and these website builders, people are moving as much as they can to the build step rather than repeatedly doing the same thing every time a web page is served. This includes things like retreiving text from urls, api calls, database queries etc. (eg. REST API, graphql, faunadb, etc.).

There’s also headless CMSs that are becoming a thing, many of them git-based. So people are also using the website generators to fetch/retrieve content from CMSs.

Plus pre-rendering markup to html during the build step is also a ‘big-thing’ with JAMstack (JAM means Javascript, APIs and Markup). So using programs like pandoc to convert markup languages to html during the build step will also be quite common.

Would these sorts of things count as services?

I was able to come up with a nice easy way to add functionality for all of that stuff by making it possible for people to execute system calls and run scripts at any point when building web pages with Nift. So on top of all the above, using Nift it’s basically possible for users to run any system call or execute any script. Hence the need for classic confinement as it’s not realistic to package every tool one might want to use with Nift (pretty sure that’s already understood, but was a good place to reiterate that).

The difference being, does the developer drive the nift process to build a website and push those pages (whether it is static html or dynamic php doesn’t matter) or does the developer use nift to drive a management agent on a fleet of devices/cloud instances/etc?

The former (building the website and pushing those pages) definitely. I’m not sure whether Nift could be used for the latter, I haven’t come across many things it can’t really do yet though…

Is it possible to be more specific about what you mean by the latter though? I’m not entirely clear. Would that include for example having Nift running on the web server and doing work there as well? As that’s something I’m hoping people find Nift useful for as well.

Edit: Nift is up to 15 times faster than its closest rival Hugo too, so I’m hoping Nift will take off at some point, especially for people making JAMstack websites with 10k+ pages, and hopefully Nift can even handle millions of pages. It’s above 300 downloads on chocolatey so is slowly starting, however still very slow with finding any linux users through Snap.

@n-ham - wrt services, I was talking about you using daemon: <something> in your snap.yaml and services (typically) run as root.

I asked all these questions because for classic confinement, there is a use case of ‘tools for local, non-root user driven configuration of/switching to development workspaces/environments’ which we understand/may allow that very closely resembles what you described in your last response (thanks for all the details!). The questions about services, root, etc is that we do not typically allow since that might constitute a ‘management application’. Basically, we don’t allow a snap to take control of entire machines (management) but we do allow a developer to drive a tool to setup environments/workspaces(/or in your case, websites), so just trying to make sure we understand everything.

Thank you for the additional details. The requirements are understood. @advocacy - can you please proceed with the vetting?

Oh, I should point out that nift is currently strict mode and snapd by design supports refreshes from classic to strict, but not strict to classic. AIUI, nift is very new and there aren’t many snap user yet (correct me). @n-ham - how do you plan to migrate existing users to classic?

@jdstrand I don’t have daemon: in the snapcraft.yaml file, see here, do have plugs home, removable media, network and network-bind though.

There aren’t many snap users of Nift yet (there’s over 300 downloads on Chocolatey which is slowly going up each day). JAMstack is still taking off and not that many websites with thousands of pages are being made yet, but once they are so far Nift and Hugo are basically people’s only choices and Nift is up to 15 times faster than Hugo.

How to get the existing Nift installers to migrate to classic, I think the best I can probably do is put up a note on the Nift website. There has already been a note in a few places on the website pointing out that you can’t do everything you normally can with Nift on Snap at the moment, so can replace those messages.

@n-ham - thanks for the additional info

@advocacy - ping regarding vetting

Vetting done, +1 from me for nift.

I would recommend putting a final strict release out before moving to classic. In that final strict release, punch the users in the face to let them know they wont get updates and need to uninstall/reinstall to do that :slight_smile:

Granting use of classic. This is now live.