These are chat archives for composer/composer

19th
Feb 2016
Daniel André Eikeland
@zegenie
Feb 19 2016 09:07
I have a question about trying to force composer to install a specific dependancy in one of our packages
there's a dependancy in our package.json on assetic (kriswallsmith/assetic), which itself has a dependancy on symfony/process: ~2.1|~3.0
I wonder if there's a way to tell composer to only install the 2.1 version, which I was thinking it should be able to determine on its own, since it's running on a php 5.4 stack
Rob
@alcohol
Feb 19 2016 10:11
you mean composer.json ?
it should install 2.x if your environment is 5.4.x
@zegenie can you elaborate a bit more?
Daniel André Eikeland
@zegenie
Feb 19 2016 10:19
that's what I thought, but it doesn't, and it's on travis, so I'm not sure why it doesn't pick the right dependancy
Rob
@alcohol
Feb 19 2016 10:19
can you link a build for me?
Daniel André Eikeland
@zegenie
Feb 19 2016 10:20
yes, looking now :)
Rob
@alcohol
Feb 19 2016 10:20
ah
because your lock file has a higher version committed
you should explicitly define the minimum php version you support in your composer.json
that will help you avoid situations such as these
alternatively, run composer update instead of install on travis
Daniel André Eikeland
@zegenie
Feb 19 2016 10:55
@alcohol is that the minimum version or specified version?
Rob
@alcohol
Feb 19 2016 10:56
what do you mean with "specified version"?
Daniel André Eikeland
@zegenie
Feb 19 2016 10:56
so, for travis with php 5.6 it would still fetch symfony 2.1?
Rob
@alcohol
Feb 19 2016 10:56
the platform configuration emulates your local php version
yes, that is correct
Daniel André Eikeland
@zegenie
Feb 19 2016 10:56
as in, is that the php version composer will use for its decision making, or will it
Rob
@alcohol
Feb 19 2016 10:56
yes
Daniel André Eikeland
@zegenie
Feb 19 2016 10:56
woops, enter key slip
ok then
thanks a bunch
Rob
@alcohol
Feb 19 2016 10:57
basically the problem you now have is, someone with an up to date php version ran composer update, and updated your lock file
and now travis is trying to use the versions in that lock file on an older php version
and running into conflicts
Daniel André Eikeland
@zegenie
Feb 19 2016 10:57
yeah
but, removing the lock file entirely would fix the issue
Rob
@alcohol
Feb 19 2016 10:57
so you can either make sure you always install dependencies that are compatible with your lowest supported version
or you can run update and ignore the lock file on travis
Daniel André Eikeland
@zegenie
Feb 19 2016 10:58
of course
Rob
@alcohol
Feb 19 2016 10:58
removing the lock file would also avoid this issue yes
most libs do not commit their lock file for this reason
but if your package is more of a project than a lib, then a lock file does have a very valid purpose
Daniel André Eikeland
@zegenie
Feb 19 2016 10:58
yeah, I've been wondering about that same thing
Rob
@alcohol
Feb 19 2016 10:58
e.g. look at symfony
Daniel André Eikeland
@zegenie
Feb 19 2016 10:58
how so?
to lock down the specific versions used for a tag?
Rob
@alcohol
Feb 19 2016 10:59
sorry, gotte go for lunch now
but i'm happy to discuss this further afterwards
Daniel André Eikeland
@zegenie
Feb 19 2016 10:59
yeah same here
absolutely, I'll still be here even if I'm afk
testing the composer update travis approach now
Daniel André Eikeland
@zegenie
Feb 19 2016 13:46
@alcohol you were of course correct that composer update as a travis build step worked
Rob
@alcohol
Feb 19 2016 13:49
well there are multiple solutions :)
Daniel André Eikeland
@zegenie
Feb 19 2016 13:58
yup
so, except explicit commit hash / tag / version locking in a tag, what would the benefits of committing and keeping and up-to-date composer lock file be?
Rob
@alcohol
Feb 19 2016 14:00
in projects?
making sure all collaborators are using the same versions
Daniel André Eikeland
@zegenie
Feb 19 2016 14:00
ah, yes