Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Templates for various Drupal VM use cases #618

Closed
nerdstein opened this issue May 13, 2016 · 16 comments

Comments

@nerdstein
Copy link
Contributor

commented May 13, 2016

DrupalVM can be used for various use cases.

The current make file and configuration YML appear to be focused on a core-contributing use case.

One other prominent use case is doing local sandboxes for a Drupal-based project. This has different needs, which include pinning of stable versions of Drupal, Drush, and dependencies (non bleeding edge so that projects can focus on their development without being burdened with potential other issues).

I'm proposing we provide at least one more example.make and example.config.yml optimized for projects. There are considerations like "working copy" of core that projects wouldn't benefit from because updating core becomes harder.

I would like to discuss the potential use cases and identify improvements to meet a broader set of needs.

@oxyc

This comment has been minimized.

Copy link
Collaborator

commented May 13, 2016

Personally I always keep my development modules in the dev branch and then disable them on production.

As for drush, from a maintenance perspective it makes sense to keep it at master so we don't have to update it every time they release a new version. I agree that this can be an issue though. Nowadays I use drupal-composer/drupal-project as the base for my sites and there I pin down the latest stable version with composer. This way the the globally installed drush delegates to the project specific drush version.

Edit: I hadn't even noticed Drupal VM uses working copy of core. Maybe we should remove this for the common use case? I bet most people don't know what this is.

@geerlingguy

This comment has been minimized.

Copy link
Owner

commented May 15, 2016

Edit: I hadn't even noticed Drupal VM uses working copy of core. Maybe we should remove this for the common use case? I bet most people don't know what this is.

Yeah, that's one of the main things. We could just comment it out and let people uncomment if they're doing core dev work or using Drupal VM at a workshop.

@geerlingguy geerlingguy changed the title Templates for various DrupalVM use cases Templates for various Drupal VM use cases May 15, 2016

oxyc added a commit to oxyc/drupal-vm that referenced this issue May 15, 2016
oxyc added a commit to oxyc/drupal-vm that referenced this issue May 15, 2016
oxyc added a commit to oxyc/drupal-vm that referenced this issue May 15, 2016
@nerdstein

This comment has been minimized.

Copy link
Contributor Author

commented May 16, 2016

The working copy is one thing. But, there are more settings ideal for initializing a Drupal project and having DrupalVM facilitate sandboxes, e.g.: pulling from a stable release of Drush, pulling stable release for Core, etc. I'm sure there is more and we need an approach that separates building a Drupal site from doing core development. This is less about the actual modules installed - I fully expect people to know and understand how to use a make file or Drush for getting what they want.

My gut tells me we should consider separate config.yml and/or make files for various use cases. At a minimum, a different set of configuration for core development and developing a website in Drupal.

geerlingguy added a commit that referenced this issue May 16, 2016
Merge pull request #630 from oxyc/issue-618
Issue #618: Disable working-copy of drupal core by default
@fubarhouse

This comment has been minimized.

Copy link

commented May 23, 2016

@nerdstein Let me assure you that with the use of things you can code yourself, DrupalVM is far more powerful than it might look on its shell. I'm now developing node, python and bash as well as drupal and php comfortably without ever worrying about it dying or being restricted.

The latest release actually allow for different configuration files - though make files are rather set and are in fact inevitably going to become redundant...

I'm actually not a fan of the new implementation of Galaxy provisioning so I've reverted those lines, but should you need different 'implementations' of it, all you need to do now is to either keep them in isolated repositories, or keep a copy of all the config files and copy them as required.

@oxyc

This comment has been minimized.

Copy link
Collaborator

commented May 23, 2016

I'm actually not a fan of the new implementation of Galaxy provisioning so I've reverted those lines

You can disable it by adding this to a Vagrantfile.local

# Disable the galaxy role re-installation during provisions.
config.vm.provisioners[0].config.galaxy_role_file = nil unless ENV['GALAXY']

(edit: made the example configurable so you can run GALAXY=1 vagrant provision to do update roles).

Or are you refering to pinned versions?

@fubarhouse

This comment has been minimized.

Copy link

commented May 23, 2016

@oxyc That's actually rather interesting, thank you for the heads up... I will let you know how that goes :)

@oxyc

This comment has been minimized.

Copy link
Collaborator

commented May 23, 2016

Also as the config/drupal-vm directory is now read from environment variables. It opens up the possibility for imaginative wrappers.

function vagrantsh() {
  local conf="$1"; shift
  DRUPALVM_CONFIG="custom-vm-configs/$conf" vagrant "$@"
}

$ vagrantsh php5 up
@nerdstein

This comment has been minimized.

Copy link
Contributor Author

commented May 23, 2016

@fubarhouse I am quite familiar with how the configuration layer of DrupalVM works. My recommendation was, instead of shipping with just one default example.config.yml/example.drupal.make is to explore the various other use cases that DrupalVM may be used for. My concern was not the usability or ease of copying or adjusting config (which I have found to be amazingly flexible), but more about having sane defaults per use case.

The use case DrupalVM ships with, by default, is for core development (talked with @geerlingguy about this at DrupalCon). One use case that I use DrupalVM for is a sandbox for Drupal-based projects. There are many settings I find to be ideal for this use case that vary from core development. As such, different config templates would limit the back and forth needed by developers to perform configuration for that use case.

Please note that this is issue is not about some limitation in DrupalVM, it's about the usability of it for additional scenarios in which someone might want to use DrupalVM. For me, personally, I'd love to see things like "--working-copy" be removed from a project-specific DrupalVM use case. That trips me up every time, along with pinned stable versions of Drush, Drupal, etc.

If no one cares about this, it's clear I have many options to work with. But, I would love to be able to pull down the most recent DrupalVM code, have example configuration for bootstrapping a Drupal project, and run with it. Precedence exists already with the 'examples' directory and the overrides concept. This may be a way to introduce the overrides needed for project-level configuration.

@geerlingguy

This comment has been minimized.

Copy link
Owner

commented May 23, 2016

For me, personally, I'd love to see things like "--working-copy" be removed from a project-specific DrupalVM use case.

That's gone from 3.0.0 :) a4e8225

pinned stable versions of Drush, Drupal, etc.

I definitely won't be pinning a version of Drupal in the config Drupal VM ships with—that's too much maintenance effort for me; but I do pin now to 'latest stable 8.1.x', and I think that's good enough for 99% of people building anything on top of Drupal VM. Most people just ignore the makefile entirely anyways :)

But we could maybe pin Drush to an 8.x release. Right now it's on master, and though it hasn't happened lately, there are times when bleeding edge is... bloody.

@nerdstein

This comment has been minimized.

Copy link
Contributor Author

commented May 23, 2016

It seems like we're mostly there :)

And, +1 to the Drush comment. I often end up pinning Drush on 99% of my installs.

@joestewart

This comment has been minimized.

Copy link
Contributor

commented May 23, 2016

Nice @oxyc I've added a check for the roles directory too.

# Disable the galaxy role re-installation during provisions.
config.vm.provisioners[0].config.galaxy_role_file = nil unless ENV['GALAXY'] || !Dir.exist?("#{host_drupalvm_dir}/provisioning/roles")
@fubarhouse

This comment has been minimized.

Copy link

commented May 24, 2016

@nerdstein drush site-install will inevitably be replaced by composer - though it wouldn't be tricky to continue to support both methods.

@joestewart I really like that, thanks :)

@thom8

This comment has been minimized.

Copy link
Collaborator

commented May 24, 2016

@nerdstein you could create a fork and manage a few install profiles (custom config.yml) as branches.

I do something similar here -- https://github.com/thom8/beetbox/branches/all
which has the added benefit of also separately testing each individual config.
*note many are failing as we've added some drupal specific tests.

Then each release I'll rebase these branches and can test if anything has broken.

eg. this branch builds out the Acquia lightning profile -- https://github.com/thom8/beetbox/tree/lightning
tests are passing -- https://circleci.com/gh/thom8/beetbox/1133
and only a small diff from master so it's often a clean rebase -- beetboxvm/beetbox@master...thom8:lightning

@nerdstein

This comment has been minimized.

Copy link
Contributor Author

commented May 25, 2016

@thom8 cool, that idea could work. I wanted to at least propose it upstream instead of maintaining my own fork.

@geerlingguy

This comment has been minimized.

Copy link
Owner

commented Jul 24, 2016

I think with the three different supported 'from-scratch' install methods, in addition to the expansion of the docs and capabilities for including Drupal VM in projects as a composer dependency, and the community support around upstream wrapper projects that integrate with Drupal VM, we're pretty well covered.

I don't want Drupal VM to try to turn into a be-all/end-all "here's how you do everything with Drupal from end-to-end" tool, but just "the best Drupal local development environment that just so happens to do a bunch of other things well and has a lot of best practices as defaults". Therefore I'm happy with where we are, and this thread has a lot of good jumping-off points for those who want to go much deeper in the realm of Drupal VM customization and Drupal build/deployment process in general.

@geerlingguy

This comment has been minimized.

Copy link
Owner

commented Jul 24, 2016

Also, we're no longer requiring galaxy roles to be installed on every provision by default, since they're included with Drupal VM (3.2.0 release with that feature coming soon!).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.