Bin conflicts
theofidry opened this issue · 4 comments
I think we already mentioned that once in a discussion somewhere, would there be a way to manage binaries conflicts?
For example say I if require PHPUnit in two namespaces (each with a different version), could this be handled? A way would be to add extra config to composer.json
to tell which one to pick, another one could be to change the link and prefix it by the namespace. For example if you have the namespaces symfony
and laravel
, you would end-up with:
vendor/bin/
- symfony-phpunit
- laravel-phpunit
Instead of just phpunit
.
WDYT?
Given how this plugin works (it's just a simple wrapper), that'd be very tricky to implement.
Nonetheless I think that this could be a feature request to ask for in composer, it can be useful outside of the scope of this plugin. Maybe a config for a bin-pattern
(with its associated COMPOSER_BIN_PATTERN
env) would be more flexible than a prefix, for instance if people use different composer projects linked to the same bin-dir which is in their $PATH, they could install different versions of a given tool easily (prefix-{name}
or {name}-5
for the version as a suffix).
AFAIK integrating such things to Composer itself is out of question (Jordi
was quite against it and I don't feel like pressuring him to do so is right
either, he already expressed his view on it and I would rather respect it
than constantly re-questioning it).
Isn't the symlink done in this plugin? I don't mind taking a look at it but
I may need you to point me out a thing or two :)
On Wednesday, 7 September 2016, Bilal Amarni notifications@github.com
wrote:
Given how this plugin works (it's just a simple wrapper), that'd be very
tricky to implement.Nonetheless I think that this could be a feature request to ask for in
composer, it can be useful outside of the scope of this plugin. Maybe a
config for a bin-pattern (with its associated COMPOSER_BIN_PATTERN env)
would be more flexible than a prefix, for instance if people use different
composer projects linked to the same bin-dir which is in their $PATH, they
could install different versions of a given tool easily (prefix-{name} or
{name}-5 for the version as a suffix).—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#6 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AE76gYN52WNwQbjxQ9n2zonuDGVUcFfRks5qnv7igaJpZM4J2CAX
.
Well, the symlink is not made from here at all. The plugin just acts as a helper :
composer bin namespace require vendor/package
Will basically run behind the scene something like :
mkdir -p vendor-bin/namespace
cd vendor-bin/namespace
COMPOSER_BIN_DIR=/bin/dir/from/main/project require vendor/package
cd ../../
And the all
namespace will loop through all directories in vendor-bin instead and run the command in each of them. So symlinks are made by Composer.
What about adding an isolated-bins
option, which would disable passing the COMPOSER_BIN_DIR
variable? Then you could run ./vendor-bin/laravel/bin/phpunit
and ./vendor-bin/symfony/bin/phpunit
.
What about adding an isolated-bins option, which would disable passing the COMPOSER_BIN_DIR variable? Then you could run ./vendor-bin/laravel/bin/phpunit and ./vendor-bin/symfony/bin/phpunit.
Looks like a good compromise. Less elegant but I don't see a better solution to solve this problem.