Add a helper to put vendor/bin in $PATH

[deviantintegral]

With composer, it's really nice to be able to lock down CLI tools like Drush on a per-project basis. However, keeping ~/.zshrc up to date with a PATH variable is a pain. This helper avoids all of that by creating a subshell with the right path that can easily be reset with an exit.

[webflo]

Drush supports this behaviour out of the box. We discussed in #52.

Drush issue: drush-ops/drush#1595

[deviantintegral]

What about other CLI tools that aren't part of drush, like phpunit, drupal console, etc? This also has the advantage of not requiring drush globally as well.

[derhasi]

In our projects we started to work around this "issue" with a little helper cli tool buddy. So we can define project specific tasks and call them by simply prefixing buddy or b. (Example: https://gist.github.com/derhasi/9edbc13de630d598336b)

[weitzman]

Even though Drush can do this internally, I still see this as a very tiny, very useful PR. If I had seen this earlier, I might not have split up Drush into finder+launcher as we did.

[greg-1-anderson]

Yes, I think this is a great PR also. Might want to update the docs to recommend folks copy it to a location already in your $PATH, as this technique is generally useful for any sort of Composer project.

OT discussion on other alternatives:

FWIIW, I have ./vendor/bin in my $PATH all the time, so that I can run executable programs from projects at the cwd all the time. Also, as far as the Drush Finder is concerned, I am looking forward to the day when the Finder understands aliases, and can handle aliases and remote dispatches. Also, did you know that Drush can be used to run other tools as well? If you source example.bashrc and alias git=gitd, then git @remote pull will run a git pull on your remote site. Want to use Drush aliases with Drupal Console? See hechoendrupal/drupal-console#1104. These sorts of techniques will be even easier with a more capable Drush Finder.

[webflo]

It does not work really well from me, because i add the composer path in my ~/.zshrc. The global composer path (~/.compoer/vendor) takes precedence over the other path.

[deviantintegral]

I'll have to catch up on drush finder.

I also have ~/.zshrc adding ~/.composer/vendor/bin. This adds ./vendor/bin at the top of the path list, so it should take precedence? I can't think of a situation where you'd want a global install to override a project install.

[webflo]

@deviantintegral It do not work if you add additional path to $PATH in your shell startup script. Has anyone a good idea for a workaround?

[deviantintegral]

I'm not seeing where it's breaking. I've got all kinds of path configuration in my shell startup, but this runs last and therefore adds the directory to the beginning of PATH. Can you provide any more details?

[greg-1-anderson]

@deviantintegral your helper adds your path to the beginning of $PATH and then starts a new shell; if the user has customized their .bashrc file et. al. to add other items (e.g. the global vendor/bin) to the head of the $PATH, then these customizations will take precedence. Hence, the usefulness of this helper script is predicated on what else might be in the user's ,bashrc file.

[deviantintegral]

I'm not coming up with any simple solutions for dealing with situations where you also want user-defined paths to be pushed to the beginning. I think this so far solves what most users need, and anything more complex can be handled individually. Or is there anything I've missed here?

[greg-1-anderson]

I don't think this is universally useful enough to justify adding another script to the project. Folks who want to use this workflow can simply define a shell alias in their .bashrc:

alias subshell='PATH=$(pwd):$PATH bash'

Then you can run subshell in any project, not just those that have a shell.sh script.

[deviantintegral]

Works for me.