Remove support for all other installation methods apart from composer

[thom8]

Motivation

Making any major changes is extremely difficult if we continue to have full BC support.
Composer allows us to version the project and let the version to continue to work with the latest release of that box.

eg. if you require beet/box ^0.4 this contains a box version constraint to 0.4.x https://github.com/beetboxvm/beetbox/blob/master/.beetbox/Vagrantfile#L19

When we release 0.5 you will no longer get updates until you upgrade the composer version at which point you may need to make modifications to your config.

Therefore the versioning will change to [major].[break BC].[patch (full BC)]

As a bonus we can also assume the project is available @ /<path to vendor>/beet/box which means we can load default config from here rather than have to deal with default config in the Vagrantfile

Relates to #372 as this will replace all default installation instructions.

[AlexSkrypnyk]

@thom8 I think is is a wonderful idea!
But before proceeding with this, could you please explain in short the workflow around working with composer. I.e., we already have CLI commands in README.txt, so what are the exact composer commands to replace those CLI ones?

[thom8]

@alexdesignworks it will basically be composer require --dev beet/box:^0.4

[christopher-hopper]

Anyone else think this is too much abstraction and a mismatch between package managers?

I'm troubled by the idea of taking a Vagrantfile away and replacing it with Composer. I found this issue because I went to readthedocs and found the install instructions no longer applied to me. They forced Composer into my existing, older project.

I love Composer, don't get me wrong, but I feel like your using PHP package management now to install a Ruby application. It just feels wrong.

At the very least, can we keep backwards compatibility somehow to support the normal Vagrant workflow that people know?

Sometimes what looks like magic just leads to confusion.

[thom8]

@christopher-hopper understand your concerns but in this case I believe its required to allow proper versioning of the Vagrantfile otherwise when you go to update the base box your project dies due to a change that breaks backwards compatibility.

If you have a better idea to resolve this issue please let me know.

[thom8]

Also you still can just drop the Vagrantfile into your old project, but you need to self manage this as it will not be supported.

Composer is the obvious choice since this is a LAMP project.

BTW it would be nice if there was a better way within the normal vagrant workflow.

@christopher-hopper and you can always pin to an older version --

eg vagrant_box_version: "= 0.4.2"

[christopher-hopper]

Thanks @thom8

yeah, dropping the Vagrantfile and pinning to a version is what I was about to do. I just lost the pointer to the wget command to get the latest Vagrantfile. It used to be on readthedocs. Could we put it back, as an install alternative? I've copied one over now from another place.

Have we considered writing a Vagrant plugin, rather than using Composer?

I don't see the link between Composer and Vagrant any more than npm or Ruby gems. I see the motivation behind it now you've explained, but I still wonder about beetbox as a Composer managed PHP package dependency. As an option, okay, but as the only documented install method, really?

[thom8]

Yeah there was originally a plan to make it a vagrant plugin, there's probably an old issue discussing it.

But this would only add more ruby and would prefer to make it easier for PRs, particularly in a PHP based VM project.

Really don't want to confuse users with multiple install methods as it adds to confusion and bigger support overhead.

Hopefully with a more streamlined usage we can fix up the doc's which has been difficult when there's different methods depending on how you first setup the project.

[AlexSkrypnyk]

@christopher-hopper It is a bit off-topic, but let me share some future plans where this benefits a big picture.
One of the good reasons to use composer for beebox is to make beetbox a part of the same toolchain as the rest of PHP tools such as PHPCS and PHPUnit etc. I'm currently working on the Robo (robo.li) package to bring it all together as a workflow, so that any project can be easily "put on the rails" of the existing workflow practised across other projects from one place - composer.json. This means that all config for items in toolchain will be living in composer.json, potentially even having some packages generating per-tool configs such as .jslint or phpcs.xml.

[christopher-hopper]

Okay. Well, if you could, pretty please, make some mention buried somewhere in the docs of the alternative (old) method of install, by self-managed Vagrantfile. and if possible, don't forbid it.

MEAN stack development could benefit from this nicely configurable local environment. Don't sell beetbox short by narrowing the focus too much.

Keep an open platform and you may be surprised where the users take it.

@alexdesignworks if you're limiting your toolchain to Composer, you're missing out surely. As I eluded to before, even Drupal dev's couldn't get by without a little Nodejs in their lives (could they?). How else do you get all that eslint csslint markdownlint Grunty Gulpy goodness? Composer is one tool, but surely not the only tool in the box.

[AlexSkrypnyk]

@christopher-hopper The toolchain is managed by composer. All the NodeJS stuff is pulled in by composer, including nodejs itself (there is a PHP package to install NodeJS). So you still use all the goodness of front-end world, but do it from one place. I.e. (improvising here): composer theme-build - builds theme assets etc.

[thom8]

Totally get what you're saying @christopher-hopper but I think the problem in the past has been that we've tried to support everything and when one thing changes it breaks something else.

Making any major changes is extremely difficult if we continue to have full BC support.

I want to be more agile and explore improvements in a way that does adversely affect current users.

So we need a stable supported installation / update path, with a proper way of dealing with breaking backwards compatibility, anyone is welcome to fork and extend if they like.

That old install method will remain in the project history -- https://github.com/beetboxvm/beetbox/commits/master/README.md

There's also a node package which I had also been testing using yeoman -- https://github.com/beetboxvm/generator-beetbox

[thom8]

And when we release 0.5.0 this project will be fine - https://github.com/thom8/drupal8-vagrant

because it specifies a version constraint - https://github.com/thom8/drupal8-vagrant/blob/master/composer.json#L11

I can then choose when to update :)

[thom8]

That old install method will remain in the project history

Apologies if this is a bit harsh but I don't want a situation where someone references this or uses it without understanding the consequences basically going forward doing this without manually pinning the version and then updating the base box will more than likely lead to issues.

We can also carry out major refactoring for things like CentOS support rather than having to worry about current are future support.

[thom8]

@alexdesignworks another option is https://github.com/eloquent/composer-npm-bridge but requires npm on the host.

On the other side you can also add the composer.phar directly to your project so you don't need to install it on the host - https://getcomposer.org/download/

This is currently being discussed as an option for Drupal to support automatic updates.

Also not too hard to retro fit an old project even if the composer.json file only contains -

{
    "require-dev": {
        "beet/box": "^0.4"
    }
}

You can still commit the Vagrantfile from there as it will have the box version constraint set --> https://github.com/beetboxvm/beetbox/blob/master/.beetbox/Vagrantfile#L19

[thom8]

linking issue -- #88

[thom8]

Fixed in #394