Commit composer.lock file.

[bar]

It is hinted by Composer documentation to commit the lock file (http://getcomposer.org/doc/01-basic-usage.md#composer-lock-the-lock-file).

It should be created using: $ php composer.phar update --no-dev

[wa0x6e]

My understanding of that hint is different from yours.

You should commit the lock file into your own vcs: the one you're sharing with other developers working on the same project, or the one used for your deployment, to ensure you're all working with the same dependencies.

The "source" should not have a composer.lock file.

[bar]

Thanks, I understand your point. Shouldn't it be excluded in .gitignore then?

[wa0x6e]

No. Since it's excluded only on the source repo.

If it appears on .gitignore, it'll prevent all other cloned repo to share the composer.lock

[bar]

What do you mean by other cloned repos?

You can ignore the composer.lock file from the root of the project without affecting other repos.

[wa0x6e]

Suppose I add the file in my .gitignore:

-> It's ignored on this source repo -> You cloned this repo to your project -> you also clone my .gitignore -> your composer.lock is now ignored -> you can't share the file anymore on your own vcs

[bar]

I can't share it right now if it is not tracked, but the moment you track it, you destroy history :p

That's why I suggested commiting composer.lock as hinted by @seldaek in PHP Conference Argentina a month ago.

[wa0x6e]

Maybe I'm not explaining it correctly, see https://github.com/laravel/laravel/issues/2293

[bar]

Thanks, that clarifies more your statement.

I agree on not having it in .gitignore, I actually have it listed in .git/info/exclude, but as I get CakeResque using git submodules, commiting in CakeResque repo just to track it is not an option.

What I dont fully understand, are the extents of Jordi's statement here, when he speaks of "libs and reusable things"; I mean, CakeResque is intended to be used just for CakePHP, it is not like guzzle for example.

[wa0x6e]

"libs and reusable things" refers to library meant to be shared, eg, this CakeResque repo, only meant to be cloned. Once on your server, it loses that status, as you're "using" it.

Another way to lock your dependencies with the lock file is to convert the submodule into a composer package: Install CakeResque with composer. That way, not only you're enforcing CakeResque dependencies' version, but CakeResque's version itself.

See http://stackoverflow.com/questions/16888781/install-cakephp-plugin-and-helper-via-composer

[bar]

From that, I guess the lock file is intended for private/unshared stuff mostly?

Yes, we have some repos as submodules because it is easier to branch and share private repos than having a satis server with private packages (for now).

[wa0x6e]

Yes, composer.lock is intended to be shared among you and your developers, and not me and you. I can't force you to be on version x.y.z, but you should force your developers to be on the same version, if you're working on the same project to avoid lines like: "But it works on my computer!" ...

[bar]

I know what you mean ¬¬. There should be an easier way to enforce dependencies without having to go all the way with composer for every submodule. But bash and composer will be for now I guess.

And thanks again for your knowledge, you have been very helpful.

[wa0x6e]

:ok_hand: