Revamp the Vagrantfile about vvv HOT 7 OPEN

I'd like us to keep to a .vvv folder, this is already supported in site provisioners and it avoids us having issues if we do things without vagrant or if vagrant changes the folder layout. Same if someone tries to debug by nuking the VM and removing the .vagrant folder

from vvv.

An example of OO or at least abstracting away duplication is the shared/mapped folders. All our mappings have the same settings yet we define them for every single provider, so a wrapper function or class representing each folder might be a more optimal way of doing it. I know other Vagrant projects have done this.

Chassis does this via configuration and an array:

https://github.com/Chassis/Chassis/blob/main/Vagrantfile#L104-L109

https://github.com/Chassis/Chassis/blob/main/Vagrantfile#L225-L232

GitHub

Chassis/Vagrantfile at main · Chassis/Chassis

📦 Chassis is a virtual server for your WordPress site, built using Vagrant. - Chassis/Vagrantfile at main · Chassis/Chassis

GitHub

Chassis/Vagrantfile at main · Chassis/Chassis

📦 Chassis is a virtual server for your WordPress site, built using Vagrant. - Chassis/Vagrantfile at main · Chassis/Chassis

from vvv.

Likewise, data collection and splash screens could be a function in a file, as could all the various big warning screens

from vvv.

I'm with you. I also think that starting off by creating a Ruby module called ``VVV` as a root namespace and then use that to namespace classes that we use, with each class in a separate file to make it easy to deal with.

I guess something like .vvv/lib/[class_name].rb would be a good idea that keeps us within needs and conventions.

I also think that scoping this so that we keep the current intended functionality and then branch into adding further functionality. I.e. starting off with some sort of MVP and going from there.

from vvv.

Looking on how we are looking to evolve the project for pure docker support and not just Vagrant a path can be .vvv/vagrant/lib[class_name].rb in this way we can use that folder for the internals things.

About the rest I agree about everything.

from vvv.

@Mte90 - That's exactly how I'm doing this currently. Maintainability and portability are the two biggest concerns that I've been having.

from vvv.

The first PR for this is ready at #2641.

from vvv.