composer.lock file environment dependant

[arnaugm]

Is it possible to use different lock files depending on the environment where I'm installing the application?
My deployment process runs "composer install --no-dev" but it doesn't take effect if the lock file, generated in devel, says that the devel related packages have to be installed. I end up with uneeded devel packages in production.

If that's not possible, which would be the correct approach?

[stof]

This should take effect. If it does not, it is a bug

[Seldaek]

Indeed install --no-dev should not include dev requirements.. If you find it is the case please provide a proper reproduce case.

[arnaugm]

So sorry, I verified you are right. A missconfiguration in the deployment process made me think that.
That rises a doubt, would it make sense to need more than one lock file?

[stof]

@arnaugm I don't think so. Non-dev requirements should be installed with the same version when running composer install with locked vendors, be it with or without dev requirements. Having 2 lock files would complicate it a lot as they could become out of sync.

[arnaugm]

Sure, I was thinking more on different test environments for example. But it's true that probably it would unecessary complicate the things.

[gggeek]

Sorry if this is not the good place to discuss this - but I seem to find little info on Google about using composer in a context where different packages/package-versions get deployed/tested to different environments.

Is that a scenario which is encouraged/supported/prevented by composer? Is it better to look elsewhere for doing the configuration mgmt in that case?

[arnaugm]

Having different packages/package-versions make the project different, at least potentially, as it can behave differently due to the difference in the third party code. In this case I would play with different git branches (if you use git) and every branch can have its own composer file.

[gggeek]

@arnaugm thanks for chiming in.
In fact I found a similar issue here: #3293
As far as I see, there are at least 3 possibilities:

• keep different composer.json files next to each other, and use and env var to pick the one you use
• use different git branches and a single composer.json
• use some CI script which builds the final composer.lock at runtime by calling 'composer require xxx/v1.2.3)
  It remains to be seen which one will make the team more productive and reduce deployment snafus...