Add Drupal VM as a dev dependency

[dickolsson]

I know that drupal-composer/drupal-project doesn't necessarily strive to provide a complete development environment. But since Drupal VM provide such a nice Composer integration I though it could be nice to include it as a dev dependency to demonstrate what can be done with it.

We're only adding two optional files (coming as .dist) and with a few super easy steps (that I have documented in the README) you have a complete dev environment! Super nice :)

[weitzman]

Seems like a good proposal to me.

[geerlingguy]

Technically, you would only need to include a few variables that need overriding (e.g. vagrant_synced_folders), instead of the entire config.yml file.

This way maintenance is a lot easier over time, since you would just use Drupal VM's defaults (which should always work with the latest and n-1 releases of Drupal core).

[dickolsson]

Thanks @geerlingguy! I just pushed a minimal version of the config file.

[geerlingguy]

This should now be ~3.5

[dickolsson]

Just fixed the feedback from @geerlingguy

[pfrenssen]

I wouldn't do this, this is just bloat. This does not satisfy the 80% rule. Who still works with a VM nowadays I wonder, this is old school practice. Also DrupalVM is using Vagrant which doesn't run well on anything else but OSX. On Linux it is difficult to set up and runs slowly. On Linux Docker is much more popular because of this reason.

If you want to use drupal-project with a VM then the best thing to advertise it is maybe to fork it and provide the VM integration in your fork. Or maybe write a blog post about it?

[PatrickBauer]

I'm not using it myself, but using vagrant for automated virtual machines is in no way old school practice. But yes I too think that the 80% rule isn't met here. On the other hand, its not really that much bloat and could help to educate some users about the possibility to use Drupal VM.

[kentr]

@pfrenssen Are you saying that Docker is more widely used than Vagrant? For dev?

To my knowledge, they're not mutually-exclusive: Vagrant is for deploying dev environments, and can do that using either Docker or a VM.

Anyway, I use Vagrant to deploy my dev environments.

[kentr]

Ah, I guess there are some obstacles in using DrupalVM with Docker.

[geerlingguy]

Who still works with a VM nowadays I wonder, this is old school practice. Also DrupalVM is using Vagrant which doesn't run well on anything else but OSX. On Linux it is difficult to set up and runs slowly. On Linux Docker is much more popular because of this reason.

While I'm fine whether this gets into the project or not (no harm either way), I would contest these statements—the idea of a modular, VM-based stack (whether that VM is a full VM or a Docker image built on top of Alpine, Debian, etc.) is what's important.

Drupal VM is useful in that you can customize the stack on top of CentOS, Ubuntu, or Debian, and match your cloud environment exactly. Docker is useful in that you can quickly bring up or rebuild your existing images. There's a middle ground between customizability and speed, as well as cross-platform experience, and at this point, (for reasons mentioned in the thread @kentr linked), Drupal VM's goals are best met using Vagrant with full OS-based base boxes—especially since 95% of the site builders and developers I work with don't use Linux, and it would be a hard sell, since there are many GUI apps essential to their workflows that don't run on that platform :)

[geerlingguy]

And to be clear—Drupal VM's tests are actually running on Docker images, as it's the best/fastest way to do CI across multiple OSes. And there are some users who have used Drupal VM to build Docker images they use for dev purposes (not sure about anyone using it for prod yet). So the playbooks behind Drupal VM are actually suited for Docker use, and will be even more so over time, as I evolve the Ansible roles to be compatible with Ansible's container specs (so they don't strongly tie to an init system, as they do now).

[worthwhileindustries]

@geerlingguy ++1 agred

[pfrenssen]

Drupal VM's goals are best met using Vagrant with full OS-based base boxes—especially since 95% of the site builders and developers I work with don't use Linux.

Yes that's exactly my point, it works great on OSX, but not on all platforms. This makes it not a good fit for drupal-project.

[geerlingguy]

Yes that's exactly my point, it works great on OSX, but not on all platforms. This makes it not a good fit for drupal-project.

Unsure how that conclusion is drawn here; working great on one platform doesn't equal not working great on other platforms. You can use LXC on Linux, and on Windows VirtualBox is about as speedy as Docker, and compatibility is about the same for a lot of things.

Vagrant is basically a glorified shell script for running VM/container-related commands... one of the benefits is that it does work exactly the same across the three platforms.

[pfrenssen]

IIRC it's not the virtualization that causes it to run so poorly on non-OSX systems, I believe it was the folder sharing between the host system and the client. I tried it extensively a few years back and simple things like single page requests worked fine, but it was pretty much unusable for heavier tasks like running tests. I had a huge performance drop (like 20-30 times slower) compared to running them native. Nowadays when I look around I only ever see OSX users that are running Vagrant, so I am assuming that it is still not fixed.

Anyway this approach of having a dedicated complete development environment running on a local machine feels old fashioned to me. The idea used to be that this solves the problem of incompatibilities between production and the local development environment, but it only helps up to a certain level and has the drawback that running a separate monolithic development environment for every project it takes up a large amount of resources. Production environments are very complex nowadays, and there is little point in trying to emulate the database clusters, reverse proxies, load balancer and everything else locally.

In practice, if you are running the same PHP version, web server and database (and maybe Redis and Solr and some other project specific components) as on production you cover 99% of all potential incompatibilities. Since we're making websites and not system level applications most of the time it doesn't really matter that you have the exact same version of Debian available in a virtual machine locally as is running on production. On the local dev environment you are fine with a couple of very lightweight Docker instances.

Then on every push you run your test suite on a test infrastructure that really closely matches production so you can detect potential problems. We're using AWS with CloudFormation for that.

[bartvanhoutte]

I agree with @pfrenssen.

1. This looks like bloat. Add it as "suggest" in composer.json instead?
2. Folder sharing between host and client on Windows isn't ideal, moreover, permissions are a complete pain in the ass. I think SMB is the only viable option when it comes to performance, however this requires some tinkering.

[pfrenssen]

I like the "suggest" option! That would definitely give more exposure to Drupal VM.

[frob]

I use DrupalVM for development.

I don't agree that it should be a dev-dependency of this project but I like the suggest option. Is there an out of the box composer project that will do the same with docker based workflows? I use mac for development and docker has given be all kinds of problems on mac. I am not looking for a suggestion personally, more of a "if this is suggesting a project for VM users, it would be nice if it also suggested something for docker users too."

[geerlingguy]

@frob - Note that Drupal VM can now be run entirely within a Docker container (no need for Vagrant or VirtualBox to be installed at all)—see http://docs.drupalvm.com/en/latest/other/docker/

[webflo]

@geerlingguy Thanks for the link. I did not know that.

I think could "hide" the additional config files behind another command. This command would inspect the project structure and generate the required config files on the provided metadata.

[frob]

I will have to check that out. I didn't know that.

[thom8]

+1 for adding Drupal VM to suggests.

Also if you're interested beetbox has zero config support for this project -- https://github.com/beetboxvm/beetbox#drupal-quickstart

& config overrides can now be managed in composer.json -- https://github.com/thom8/drupal8-vagrant/blob/master/composer.json#L26

[lhridley]

-1 for adding DrupalVM as a dependency.

We have a distributed workforce, with some in places where broadband is not necessarily available. We also provide ongoing support and maintenance for several projects, and implement composer as a dependency management tool, utilizing this project on D8 sites; as a result we may have developers switching between 5-6 projects on a given workday.

For our team members in locations where broadband is not necessarily available, a build using DrupalVM takes as much as 2 hours to generate, and ties up a developer machine during the build process. We utilize virtualbox images that have software preconfigured / preinstalled, and our own Vagrantfile for VM based projects (or custom docker stacks with a customized docker-compose.yml and install scripts). Adding DrupalVM would mean that this project becomes immediately significantly less useful for our team.

A better suggestion IMO would be to add documentation to the project with instructions on implementing DrupalVM if a developer wishes to utilize DrupalVM to initiate a local developer environment.

[wundo]

Please don't, drupal-project is very well used without drupal-vm, there is no need to force this dependecy

[weitzman]

This PR would not force anyone to do anything. This drupal-project is just a template of best practices. After you run your composer create-project, you are supposed to customize your new composer.json to taste. If this PR gets accepted, folks who don't use Drupal VM would just delete one line from their new composer.json and never think about it again.

[worthwhileindustries]

I use Docker. Please don't. This is a template for drupal composer installs and not meant to be a full dev environment.

[FatherShawn]

I like the "suggest" option! That would definitely give more exposure to Drupal VM.

I think suggest is great! We've also just released a Docker local dev setup based on drupal-project: Ballast. I think the fact that drupal-project is inspiring others to built on top of it is a sign of health for this project and it should continue to encourage a variety of uses.

[weitzman]

I think there isn't enough consensus here.