Docs: Cross platform install command

[christopher-hopper]

Proposed Changes

In the ongoing quest to modernise this documentation, I submit this change to probably the most important, most read, most used part: The install commands

• Make install commands work cross-platform without additional requirements
• Future proof Drush download commands

Explanation

Why remove curl and why not use wget instead?

Because neither curl nor wget are available on all platforms where Vagrant and Drush are used. CentOS does not have wget by default and curl is a developer library that also must be downloaded on most platforms.

So why PHP, as it's not installed by default on all platforms?

We switch to PHP for download in line with both Composer and Drush installers. It is highly likely that our users will have PHP, particularly when a Drush command forms part of our install instructions.

Relates To

• Issue #255

Notify

• @thom8 - you look like the last one to touch the Install commands.

[christopher-hopper]

I have a question about Read the Docs and its Markdown implementation.

Does RTFD support language identifiers in code blocks?

Example:

```sh
if [ -n "$VAR" ]; then 
  echo $VAR
fi
```

It adds some syntax highlighting to the output.

This:

if [ -n "$VAR" ]; then 
  echo $VAR
fi

Becomes this:

if [ -n "$VAR" ]; then 
  echo $VAR
fi

I ask because I'd switch the current install command block as follows:

diff --git a/docs/index.md b/docs/index.md
index c6c01c2..fcca035 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -10,7 +10,7 @@

 ## Quickstart

-```
+```sh
 composer require --dev beet/box
 vagrant up
@@ -23,7 +23,7 @@ You can see some examples in [`config.yml`](https://github.com/beetboxvm/beetbox

 To get a simple Drupal 8 site up and running with Beetbox, run the following commands:

-```
+```sh
 drush pm-download drupal-8 --drupal-project-rename=drupal8 && cd drupal8
 php -r "readfile('https://raw.githubusercontent.com/beetboxvm/beetbox/master/Vagrantfile');" > Vagrantfile
 vagrant up

[thom8]

@christopher-hopper agree that we should limit as many host dependencies as possible.

Do you think we drop the drush dependency as well and just use composer?

composer create-project --stability dev -n drupal-composer/drupal-project:8.x-dev drupal8 && cd $_
composer require --dev beet/box
vagrant up

[thom8]

Just updated my sprintbox project to use composer -- https://github.com/thom8/drupal8-vagrant

so the following will setup and install the latest dev version of drupal.

composer create-project thom8/drupal8-vagrant d8-sprintbox && cd $_ && vagrant up

[christopher-hopper]

@thom8 My personal preference would be to have both options documented. Some people will be either unable or unwilling to use Composer. Having an option to get started in the normal Vagrant way seems good. Remove Drush if you like, but keep an option to just download a Vagrantfile and type vagrant up.

[christopher-hopper]

@thom8 interesting composer project you made. Nice work. I'll probably be sticking with this one for now though:

https://github.com/drupal-composer/drupal-project

[thom8]

@christopher-hopper good call, there's an issue with composer create-project drupal-composer/drupal-project as the docroot is at /web by default therefore the config would need to be pre populated with beet_root: "{{ beet_base }}/web".

Also, drupal8-vagrant is a project specifically for working on drupal core built for code sprints but you can fork this and customise the config to use as a starting point for your projects.

[christopher-hopper]

@thom8 the root of ./web is used commonly by Symfony, so it's good that you support that in Vagrant beet/box.

Having the Drupal Root at ./web is not so much an issue though. When deploying to platforms that don't support ./web I symlink it to ./docroot and commit that to Git. Works just fine.

Something that has confused me a bit about beet/box is the difference and use-case for having:

• beet_base
• beet_root
• beet_web

My experience has been that you cannot set beet_web to a different path to beet_root, even if it's a sub-folder of beet_root. Why does it exist? What's the use case? Maybe I should raise that as an issue, not sure.

[thom8]

@christopher-hopper just pushed a PR which could help here.

beet_base is a legacy variable where you could potentially override the mount point in the VM, I'm not sure if anyone is using this and should probably be statically defined. However, having it as a var means if we ever did change the default (/var/beetbox) it wouldn't break any custom tasks which use it..

beet_root is basically the only pre provisioned vhost and it's mainly used in project roles as the working directory, so if a project needs to be cloned/downloaded automatically it downloaded here. Also in drupal any drush commands use this path as the root directory.

beet_web is this special case where you want the project built to one directory and the default vhost path to be somewhere else.

Here's some use cases for beet_web :

drupal-composer - https://github.com/beetboxvm/beetbox/blob/master/.beetbox/config.yml#L43-L49

And Symfony - https://github.com/beetboxvm/beetbox/blob/master/.beetbox/config.yml#L79-L83

[thom8]

Also by default they are all the same -- https://github.com/beetboxvm/beetbox/blob/master/provisioning/ansible/config/default.config.yml#L21-L23

/var/beetbox is the mount point inside the VM the default project/working directory and default vhost for http and https.