At the beginning of the year I started coding a LEMP stack builder (qycli) for WordPress hosting. I soon noticed it is a bit of a mess to try to offer different PHP versions on different LTS Ubuntu versions and finally found Snapcraft as a way to package my BASH code and the dependencies.
Thank you for providing this tool dear Snapcrafters!
As one cannot easily create their own Tracks and as the “version” global metadata in the YAML file cannot be used to install only a certain version I wanted to ask if it is ok to put different PHP versions in different Snaps?
MariaDB, NGINX and redis should always be up to date, there I do not see an issue. But there is a need for some users to stay on a certain PHP version, even though it might not be supported anymore. I e.g. have to stay on 7.4 still, as a WP Plugin, that I need, does not yet support 8.0.
You’re free to create multiple snaps if that fits your needs and there’s already snaps on the store that use this approach, but I wouldn’t discard tracks just because they can’t currently be created on the user side. This sounds like a scenario that would be granted access to tracks and aside from the initial voting period of a week, most tracks thereafter are created pretty rapidly upon request (within hours) if they fit the same cadence, which the PHP versions likely would do. Simplified track request process for snaps with predictable cadence - #4 by roadmr
I think generally speaking people would rather you used tracks if it’s technically possible for you to do so, it neatens the store up and simplifies management. With the parallel installation feature you could even still have the different versions installed side by side. But there are some scenarios where tracks aren’t useful such as content snaps, and the many snaps for many versions approach becomes the only valid option.
Thank you very much @James-Carroll! You’re reply had the perfect length and depth, so no need for the TL;DR.
I will most probably make many snaps for PHP for the following reasons:
The main snap would be pretty bloated at the point of PHP 8.3 with me wanting/having to still leave 7.4 in there for those who need it and probably all the versions in between: 7.4, 8.0, 8.1, 8.2, 8.3. So 4 PHP versions laying around useless
at that point
The process remains under my control and does not interfere with my timetable. It can be automated only if no human interaction is involved. I wouldn’t mind going through something like that once, but if somebody has to approve every subversion… Should be a user permission after the initial check and approval process (just my opinion).
The store will not be cluttered by my PHP snaps as I will make them unlisted and install them from the main snap
Thanks again for your input, you have helped me a lot!
Note that if you’re providing a strict confined snap, you won’t be able to talk to snapd to ask it to install other snaps, or call commands provided by other snaps. To a limited extent you can use the content interface to trigger the install of other snaps, but it might be easier to try an all-in-one snap as a first go.
If the aim is to provide a full WordPress install, perhaps take a look at the Nextcloud snap as an example of packaging a PHP web app with backend database.
I might leave the BASH script outside of the snaps and keep installing it with wget -qO- qyc.li/inst | sudo bash from GitHub and then install the two stack component snaps from the BASH script.
I thought (as I saw some scripts in the Nextcloud snap) that you can dump stuff inside a snap and then copy some files to other directories at snap start (also with confined snaps)? This way I could put the BASH script in the snap, put it in the correct sbin folder and then run it and install other snaps with it.
P.S.: Unlike the Nextcloud snap, WordPress will always be downloaded from wordpress.org by the BASH script and never be included in the snap itself. When additional PHP scripts might be added in the future they will also be downloaded from the maker. This limits unnecessary snap compiling and refreshes, keeps the snap smaller and all of it more modular.
