Idea: Build stacks dynamically from pieces

[ocdtrekkie]

So, I realized that when I fixed the LEMP stack, I needed to make many of the same changes (re: PHP) to the LESP stack. And I've realized today that the UWSGI stack needs the MySQL fixes I made to the LEMP stack. Etc. There's a lot of common components, and many of the stack scripts more or less fit the same format: Create folders for language, create folders for database, wait for language server, wait for database server, launch web server.

While I know there would be a fairly painful nest of things to touch on (such as a PHP line in the Nginx config), I wonder if a future version of vagrant-spk should let you pick a language and a database, and then it assemble the scripts then and there for that combination.

So setupvm php+mysql might replace "lemp", setupvm php+sqlite might replace "lesp", and setupvm php-mariadb might use the same code for the PHP part, but swap out the required section of MySQL for whatever gets MariaDB running. And then instead of needing a separate stack for each likely combination, we can add languages and add components, and only have to update the code for each in one place?

[zenhack]

@orblivion suggestted on IRC just having stand-alone versions of each part of the script, so that an app's setup.sh/launch.sh might look like:

setup-maria-db
setup-nginx
# ...

Which I like.

Re: the overlap between general nginx config and php, nginx's config format supports an include directive, so having a line in the generic config like include nginx.conf.d/*.conf (I forget the exact syntax off-hand) is common, and could work here, so the php+nginx stack could just provide a file nginx.conf.d/php.conf and we could re-use the "common" nginx component for everything else.

[ocdtrekkie]

I think we want to make sure there is an automatic/easy way to start a composable stack.

setupvm php+mysql, for example, could entail detecting there's a + sign, and grabbing scripts from each side and then creating setup.sh to call them. Or we could do something like setupvm composable and then have a separate command for dropping in components after setup. But vagrant-spk has thus far avoided editing existing files (preferring to either tell you what to change, or in the case of upgradevm, overwrite them), which I imagine you'd need to do to add components later.

[ocdtrekkie]

In the short term, I would honestly be interested if @orblivion PR'd a Postgres stack that just included what needed to be done to get Postgres working. It'd be handy to reference or manually hack upon even if it wasn't a complete "stack".

[ocdtrekkie]

.sandstorm/components//{setup,launch,...}.sh

This seems sensible to me. I am not sure everything that needs to be copied and moved and changed to set up the stacks after we have them though. I might just create the components for lemp by splitting up stuff from the existing stacks, and then just try to manually wire up building the lemp stack outside of vagrant-spk so I can see what I'd all need to do including the new folder locations and everything. I know vagrant-spk has specific code for handling things like the service-config folder and such, so we'll have to see how much we can reuse existing code and how much we just want to trailblaze a bit.

The big thing is I don't want to break the existing design of stacks until we are 100% sure this is going to work well and be the way forward. (I trust the previous authors of vagrant-spk much more than I trust myself.) And then we should essentially convert our existing static stacks to be convenient shortcuts for invoking commonly composed stacks, which can be done one at a time if needbe.

[orblivion]

In the short term, I would honestly be interested if @orblivion PR'd a Postgres stack that just included what needed to be done to get Postgres working. It'd be handy to reference or manually hack upon even if it wasn't a complete "stack".

I'll make a note of it. I'd like to see it working within my current app first. I got past a handful of hurdles and I see signs of it working, but I'm not sure yet.