4

By the way, I’m lacking some sleep and I seem to be mind blocked right now, which may make this seem like senseless rants to you, so please try to take them patiently if they don’t look so.

I’m working on OS X Snow Leopard. I won’t lie how I enjoy having access to binaries PEAR sets up for me. I simply brew unlink php53 and brew link php53 after I’ve installed PEAR packages, so I get their binaries in /usr/local/bin.

Take Behat, for instance. If I install it through PEAR (now outdated), I do the procedure above, and I instantly have access to it through behat, and just that. If I were to symlink the whole bin folder Composer generated, I would get three “commands” besides behat: behat.bat and release.

Am I doing something wrong? Isn’t there a way to centralize the right binaries for example on /usr/local/bin, preferably without having to add a new path to $PATH? Is there a way to do it through Composer?

I’m thinking of npm where you can set global and local versions of the modules. I would like comfortable global versions of the (correct) binaries. Kind of gemsets, without really duplicating stuff unnecessarily.

You see? It’s a lot of mixed information, but that’s how my head feels right now. I suppose I’m looking for something like this other question, just applied to “vendor” binaries.

Thanks in advance!

PS: If I really sound like a miserable human being, let me know and I’ll rephrase my message at first hour after a good sleep. Thanks!

Community
  • 1
  • 1
Andrés Botero
  • 1,042
  • 2
  • 10
  • 26

1 Answers1

6

The thing is that if you install stuff globally, what happens when one project needs Behat 1.5 and another Behat 2.0 (imaginary versions) which are not compatible? Installing those tools in the project itself with require-dev is a good way to solve this problem. Then you just call bin/behat in your project and that's that (assuming you put a bin-dir: bin in your composer config, otherwise it's vendor/bin/behat).

Regarding behat.bat and release, that won't happen. Those files are present in behat itself, but they won't be linked in the composer bin directory.

Finally if you really want to have it global, you can have ~/phputils/composer.json or something with:

{
     "require": {
         "behat/behat": "*"
     },
     "config": {
         "bin-dir": "/usr/local/bin"
     }
}

I'm not sure the absolute bin-dir works at the moment, and I'm especially not sure if it's a great idea to do this, but it's an option. Preferably I would say you should just put it as "bin" and add ~/phputils/bin to your PATH. Then you can go in that directory, run composer install/update and that's it.

There is also the trick of doing a composer-g shell script in your /usr/local/bin that does a cd ~/phputils/ && composer $* so you can call composer-g update behat/behat from anywhere.

Seldaek
  • 40,986
  • 9
  • 97
  • 77
  • RubyGems would handle those two versions globally as well. I would pick them up per project. Bundle would make sure the correct binaries were inside each project as a safeguard, but I could still use the global ones. I mentioned the two extra files in `bin` because I installed `behat` through Packagist, and they did come inside that folder. I think what I’m wanting right now is to “use” the packages per project, but using a single, global installation. I had thought of your solution, I just didn’t want to do it myself. I’m going to support Composer so it just matures with more features. Thanks – Andrés Botero Jul 18 '12 at 15:13
  • What you describe is interesting, and we could do that at some point. There is the link command that is more or less planned (https://github.com/composer/composer/issues/601) which should help with this use case too. Anyway feel free to check open issues and comment here and there. We can always use input from people having used other tools extensively. – Seldaek Jul 18 '12 at 15:40
  • I had not noticed/checked you’re one of Composer core developers, haha. In any case, thanks for your support! – Andrés Botero Jul 18 '12 at 16:45