VVV
VVV copied to clipboard
Varying-Vagrant-Vagrants
Revamp the Vagrantfile
For the ease of maintenance and further development, doing a rewrite of the Vagrantfile may be a good idea.
- Introducing a more object oriented style, as opposed to using globals everwhere
- Splitting the main Vagrantfile into included file, located in
.vagrant/ - Setting up and configuring rubocop so that any Ruby code follows the Ruby Style Guide
- Configuring a Github action for running rubocop against any Ruby code
Describe alternatives you've considered
Maintaining the Vagrantfile as-is is an option, but with things like plugin checks being broken and the code quality having gone down over time, I think this is more sustainable.
Additional context
This was discussed in #2638 and I think that while challenging, this may be the best way for myself to start getting acquainted with the structure of this project.
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
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 is a virtual server for your WordPress site, built using Vagrant. - Chassis/Vagrantfile at main · Chassis/Chassis
📦 Chassis is a virtual server for your WordPress site, built using Vagrant. - Chassis/Vagrantfile at main · Chassis/Chassis
Likewise, data collection and splash screens could be a function in a file, as could all the various big warning screens
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.
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.
@Mte90 - That's exactly how I'm doing this currently. Maintainability and portability are the two biggest concerns that I've been having.