Set bash PATH for Composer vendor binaries

[christopher-hopper]

When I have Composer installed dependencies in my project, I'd prefer to use their vendor binaries to any installed as part of beetbox. For example, when we have Drush as a Composer managed dependency, at a specific version in our project, I want to have that preferred over the version installed by beetbox.

The following Pull Request is a suggestion. I've been copying it as a post task to beetbox projects to save me getting everyone to add these lines to their beetbox ~/.bashrc:

# Add Beetbox project vendor binaries to PATH.
if [ -d "/var/beetbox/vendor/bin" ]; then
  export PATH="/var/beetbox/vendor/bin:$PATH";
fi

[christopher-hopper]

This composer_home_path may not be required as I think it is added to the path already in the Ansible composer role (I just saw that fly by in the circle-ci tests). I'd included it here as a fallback.

[thom8]

@christopher-hopper thanks for the PR -- I have an existing PR open on the composer role which would address this -- geerlingguy/ansible-role-composer#26

It would be my preference to include it in the upstream role (+1 if you want) but if we can't get it included, we may need to fork this role as any composer related tasks should be in the composer role.

To provide a bit of background, I've been trying to remove as many tasks/roles from the core project and move them into external roles -- http://beetbox.readthedocs.io/en/latest/contributing/contributing/

The goal is to minimise the support requirements on the core project and push features back to roles which can be maintained externally.

[christopher-hopper]

There is a pull request #333 here for a new beetboxvm.composer project role. Should I be sending this over to there for inclusion into its tasks/main.yml

[thom8]

@christopher-hopper the composer project role will be only for initialising a custom composer based project, this will hopefully be a generic replacement for many projects which now only require a simple composer install to build.

You can only have a single active project role so it would be better for this to be added to the composer role - https://github.com/beetboxvm/beetbox/blob/master/provisioning/ansible/playbook-provision.yml#L57

[christopher-hopper]

@thom8
I get the reasoning behind trying to move this to a tested upstream role and out of the base beetbox/beetboxvm project. It's a good idea. Not sure though about its applicability to the geerlingguy/ansible-role-composer role. I guess in the end that'll be decided by the maintainer there.

IMO this PATH variable change is a bit of glue, specific to the way this project uses that geerlingguy/ansible-role-composer role, and might be more properly added to your beetboxvm/ansible-role-beetbox-composer role.

Let's see how that pans out anyway. Feel free to take any ideas from this suggested change into either beetboxvm/ansible-role-beetbox-composer or geerlingguy/ansible-role-composer#26

[thom8]

@christopher-hopper doesn't look like there's much support upstream, however I'm reluctant to include it inside the beetbox-init as I plan to decommission this once all tasks have been migrated upstream or into external roles.

How about we look at creating a more generic role to manage your PATH?

It could support 2 list vars for global and user in an external role and then we set this to run by default with some defaults for composer.

I'm sure it could come in handy for other package managers as well.

[christopher-hopper]

@thom8
The generic role could be the beetboxvm/ansible-role-beetbox-composer one you've already created perhaps?

You wouldn't need a variable for the global composer vendor binaries path. That's going to always be the same. As for the project vendor binaries path, that would vary depending on the project composer.json, however the code I proposed just checks up the folder tree until it finds one (if at all):

• beet_base
• beet_root
• beet_web

You could make it configurable, but default to that behaviour.

[christopher-hopper]

@thom8
To find the Composer global home, you simply run this:

composer config --global home

Then to find the global vendor binaries path, you run this and concatenate the two:

composer config --global bin-dir

So no need to add a variable for the composer global vendor binaries path. You just ensure that the new ansible role you propose is run after composer is installed, then execute those commands to find the path for global vendor binaries as the vagrant user.

[christopher-hopper]

@thom8 perhaps it would be worth adding a variable to specify where the composer project's composer.json is located. Then you will have the ability to ask it where the project vendor binaries have been placed.

This vendor binaries path can be changed in the composer.json, so could be looked up from there. You'd use a similar command to the one's shown above.

composer config bin-dir

That would give you the vendor binaries path for the project.

[thom8]

@christopher-hopper the new composer role is a project role. Project roles are special in the fact that you can only have 1 active at a time, other examples are here -- https://github.com/beetboxvm/beetbox#project-roles

beet_project: drupal by default

I'm suggesting that we create a role specifically for managing your PATH so it would be something like ansible-role-path which would be able to include any path, with a conditional that confirmed the path existed to avoid any issues.

eg. [ -d "<< path >>" ] && export PATH="<< path >>:$PATH";

This project can then include some default paths which would safely only be included if they existed otherwise it can be overridden to your requirements.

eg.

path_global:
  - "~/.composer/bin"
path_user:
  - "{{ beet_base }}/vendor/bin"
  - "{{ beet_root }}/vendor/bin"
  - "{{ beet_web }}/vendor/bin"

path_global would add paths to /etc/profile.d/global-paths.sh
path_user would add them to /home/{{ beet_user }}/.bashrc

[thom8]

the major benefit of externalising this that we can add better test coverage to the new role.

[thom8]

Rather than adding the project bin directory to the PATH you can also use composer scripts -- https://pantheon.io/blog/writing-composer-scripts

When Composer runs a script, it first places vendor/bin on the head of the $PATH environment variable, so that any tools provided by any dependency of the current project will be given precedence over tools in the global search path.

[christopher-hopper]

@thom8 I've done a bit of work with composer scripts and maybe you're right, perhaps this is better implemented per-project using a composer script. In fact I wouldn't be at all surprised if there weren't a Packagist project out there already that can just be added as a requirement to a project to set-up the PATH on install/update.