Add DrupalVM 3.0 support to BLT projects

[dpagini]

Offering up this commit to BLT project, as I am trying to incorporate something similar into acquia-pso/voya_im (private repo), a BLT based project.
This will add DrupalVM support to all BLT projects, regardless of the desire to use it. I don't think it's huge overhead, however, as it's a few files (2?), and an additional composer dependency. There are other tools brought in through this default composer.json (drupal console, for example) that might be precedent for pulling in optional tools.

Please feel free to reject if this is not an appropriate direction, or offer up suggested changes. @danepowell suggested I create this as a possible BLT change since I implemented a similar approach in our repo.

I look forward to hearing any thoughts.

cc: @geerlingguy - making sure you get a chance to comment on this. And, thank you for all your work on DrupalVM!!

[geerlingguy]

Should be 'Drupal VM' (here and in other instances).

[geerlingguy]

Also, we might want to just drop the '3.0' part, since presumably, I won't ever break this kind of integration in 3.x/4.x and beyond :D

[dpagini]

If I leave the above section, where drupal-vm was meant to be pulled into a "box" folder, I wanted to state that specifically "> 3.0" was now supported automatically in the project. This entire README should be looked at when a decision is made on this, I think.

[danepowell]

@geerlingguy I was also wondering what you thought about using the /config/drupalvm directory. I think /config should only contain Drupal config export yml files, and Drupal VM config should live elsewhere... but I don't really know where. /drupalvm/config?

[geerlingguy]

@danepowell - Ideally, there would be no additional config required (besides the delegated project Vagrantfile)—but if there does need to be an additional config file, that's a better question for @grasmash maybe... I don't want to have to help debug weird issues where BLT's config goes out of sync with the latest stable version of Drupal VM's.

[geerlingguy]

Originally I was opposed to including a config.yml file here. But maybe I'm okay with it in the case of BLT as long as we stabilize on a minor version of Drupal VM. Basically, I won't break your config.yml on 3.0.x, or 3.1.x, but between 3.0 and 3.1 there might be a change required.

The thing is, someone will need to make sure BLT's config.yml is updated any time there's a minor release of Drupal VM if we go that route.

It could just be a documentation thing—"If you use Drupal VM, you should also make these changes to the project's config.yml", and list the changes.

[dpagini]

So, I almost feel like the config.yml that actually makes it into a project repo should be project specific, no? If your project uses solr, you would want your project's config.yml to build that into the VM. ...but to your point, that probably means fixing onto a version of drupal-vm.

[oxyc]

Drupal VM 3.1.0 would make this a lot easier with the defaults pre-set.

Then you'd just need:

vagrant_hostname: ${project.machine_name}.local
vagrant_machine_name: ${project.machine_name}
vagrant_ip: 0.0.0.0

vagrant_synced_folders:
  - local_path: ./
    destination: /var/www/${project.machine_name}
    type: nfs
    create: true

drupal_core_path: "/var/www/${project.machine_name}/docroot"
drupal_site_name: "${project.human_name}"

Why not even default the upstream local_path to ./ instead of the current ~/Sites/drupalvm. Seems like a saner default no?

Then the config.yml could be as short as:

vagrant_hostname: ${project.machine_name}.local
vagrant_machine_name: ${project.machine_name}
vagrant_ip: 0.0.0.0
drupal_site_name: "${project.human_name}"

[geerlingguy]

@oxyc++ - maybe I could fast-track that issue... :)

[oxyc]

Forgot we also need (@dpagini remembered :)) :

build_makefile: false

I guess that will be removed in 3.2.0 or something? :)

[oxyc]

Then there's the Vagrantfile.local as well.

[grasmash]

I'd like to keep all of the drupal vm related config isolated in one directory, if possible. In past we've used box because it's simple. Seems like the yml and Vagrantfile would go well there.

[oxyc]

The Vagrantfile needs to be in a parent directory of both the config and the Drupal VM codebase. As composer is used that means the Vagrantfile needs to be in a directory above vendor/.

Edit: Actually I guess it works if you adjust the DRUPALVM_PROJECT_ROOT variable to point to a mutual parent directory.

[dpagini]

So "defaults" are coming in Drupal VM 3.1? That sounds like an awesome new feature!

I tend to think with the "box" approach that has been in BLT up to now, that folder was the optional place to put Drupal VM if you wanted to use it (it was not even gitignored though). If we do pull the tool into all projects with this PR, I sort of think there's a benefit to being able to run all commands from the root (which means the Vagrantfile really needs to be in the root). Maybe there could be a blt phing task to fire up drupal-vm? Then we could put the Vagrantfile and config.yml wherever we want?

If the Vagrantfile could go anywhere, @grasmash, you're saying it makes the most sense in a new "box" folder? Is that to say that "config" should only be for Drupal related config? What if in "config" we had a "tools" folder, and a "drupal" folder. Just throwing an idea out there. If we did that, maybe the "drush" folder could move under "config" as well, as that folder seems to be primarily configuration related items...?

As I'm pretty new to this open source contributing, please feel free to boss me around if I need to update this PR at some point. I'm not totally sure on next steps, and feel a little over my head here. I hope my contributions and opinions are helpful.

[danepowell]

I'm not opposed to consolidating directories, but /config has a very specific use in D8, so I'd prefer not to overload that with anything not directly related to the D8 config sync system. I don't know that it would necessarily break anything, but it just feels dirty 😄

[dpagini]

Maybe just a "tools" directory? ./tools/drupal-vm/ and ./tools/drush/, for starters.

(I say that not even knowing/testing if the "drush" directory can move)

[grasmash]

I think that we should keep the top level config dir for drupal config only. "Configuration" is now a loaded term in Drupal 8 given the existence of the configuration management system. While other things like drush could be considered config, I think we need to be very careful with when and where we choose to use the term.

I'd suggest using the box dir for the VM. If you need a config dir for the VM, you can use box/config or other various subdirectories. That seems clear enough.

I would not be opposed to adding a few VM targets. The trouble is that we can't test them via Travis, but that's unavoidable.

[geerlingguy]

Note that Drupal VM's 3.1.0 release should happen within a couple days—currently the last issue being worked on is composer.json Drupal site build support. Once that's done, I'm going to tag a 3.1.0 release that includes the default.config.yml configuration setup, so BLT would only need to generate a very small/efficient config.yml file with BLT/Acquia-recommended overrides, and then developers could add additional local overrides (e.g. extra RAM if the dev is lucky enough to have 16+ GB of RAM) in a gitignored local.config.yml file.

[grasmash]

Based on the comments in this PR, I've started another PR for Drupal VM 3.1 integration: #105

This makes use of a vm:init target, which will initialize the project for Drupal VM by moving files into the correct places.

[grasmash]

Close in favor of #105, thanks for all the help everyone.