composer is available in travis workers #5548
Conversation
| @@ -6,7 +6,6 @@ php: | |||
| - 5.4 | |||
|
|
|||
| before_script: | |||
| - curl -s http://getcomposer.org/installer | php | |||
| - COMPOSER_ROOT_VERSION=dev-master php composer.phar --dev install | |||
| - composer --dev install | |||
There was a problem hiding this comment.
missing the COMPOSER_ROOT env variable.
There was a problem hiding this comment.
why is it needed? this PR is not even against master :)
There was a problem hiding this comment.
Some composer bug, cant remember precisely why. But it should be left there.
There was a problem hiding this comment.
let's wait for a review then, if the bug is still there that's probably not the good fix anymore as this is not the master branch
There was a problem hiding this comment.
this ensures that even in branches from master it will consider the installed version as "dev-master", which is necessary f.e. for cyclic dependencies
There was a problem hiding this comment.
And it's not a composer bug per se. It's a side effect of all the auto-versioning magic and we can't really fix it, but given it only affects a few packages it sounds worth the benefits.
|
reverted |
|
btw, in the 2.1 branch, the |
|
@stof: ok, btw I don't understand the issue, deps are solvable without this, is it a workaround to make this package known as 2.1 even though it's not guessable with the branch name (eg. when using a feature branch for a PR)? I thought this was handled by the branch-alias. |
|
@bamarni It is solvable in some cases but not in all of them. Sometimes, when being in a detached head (which is the case when Travis builds PRs), the guessing of the composer root version does not work, and so symfony dev deps depending on some symfony components (Doctrine) will fail because the guessed version would not match branch aliases have nothing to do with the guessing of the version for the root package. |
|
btw, the only cases where COMPOSER_ROOT_VERSION could be needed is when some of your dependencies have a requirement on your root package. Otherwise, the root version is never needed by composer to resolve deps |
|
@stof: in detached head indeed the version can't be guessed with git, so this change avoid potential issues with reciprocal dependencies (I guess it can also be solved by specifying a "version" in composer.json). But I still don't get why you say branch aliases have nothing to do with the root package version, isn't the purpose of a "2.1-dev" branch-alias to be matched when specifying this package as a dependency with 2.1.*, no matter the branch name or if git is in detached head? |
|
@bamarni a branch alias is about the aliasing the version of a branch. Look at how it is written. It tells composer that for Symfony, the |
|
ahh... in my mind branch alias was only an alias for the current branch, I forgot that it was a 'branch => alias' map, indeed in that case it can't help at all. thx for the explanations ;) |
Commits ------- 589a8b3 composer is available in travis workers Discussion ---------- composer is available in travis workers --------------------------------------------------------------------------- by bamarni at 2012-09-19T09:07:30Z reverted --------------------------------------------------------------------------- by stof at 2012-09-19T09:59:21Z btw, in the 2.1 branch, the ``COMPOSER_ROOT_VERSION`` varaible should be set to ``2.1.x-dev`` --------------------------------------------------------------------------- by bamarni at 2012-09-19T14:44:48Z @stof: ok, btw I don't understand the issue, deps are solvable without this, is it a workaround to make this package known as 2.1 even though it's not guessable with the branch name (eg. when using a feature branch for a PR)? I thought this was handled by the branch-alias. --------------------------------------------------------------------------- by stof at 2012-09-19T15:54:05Z @bamarni It is solvable in some cases but not in all of them. Sometimes, when being in a detached head (which is the case when Travis builds PRs), the guessing of the composer root version does not work, and so symfony dev deps depending on some symfony components (Doctrine) will fail because the guessed version would not match ``2.*`` (which is the Doctrine requirement for the components). branch aliases have nothing to do with the guessing of the version for the root package. --------------------------------------------------------------------------- by stof at 2012-09-19T15:55:25Z btw, the only cases where COMPOSER_ROOT_VERSION could be needed is when some of your dependencies have a requirement on your root package. Otherwise, the root version is never needed by composer to resolve deps --------------------------------------------------------------------------- by bamarni at 2012-09-19T16:52:52Z @stof: in detached head indeed the version can't be guessed with git, so this change avoid potential issues with reciprocal dependencies (I guess it can also be solved by specifying a "version" in composer.json). But I still don't get why you say branch aliases have nothing to do with the root package version, isn't the purpose of a "2.1-dev" branch-alias to be matched when specifying this package as a dependency with 2.1.*, no matter the branch name or if git is in detached head? --------------------------------------------------------------------------- by stof at 2012-09-19T18:59:13Z @bamarni a **branch** alias is about the aliasing the version of a branch. Look at how it is written. It tells composer that for Symfony, the ``dev-master`` version (so the master branch) should receive an alias ``2.2.x-dev``. This alias will never help you if your root version cannot be guessed as being ``dev-master``. --------------------------------------------------------------------------- by bamarni at 2012-09-19T20:43:19Z ahh... in my mind branch alias was only an alias for the current branch, I forgot that it was a 'branch => alias' map, indeed in that case it can't help at all. thx for the explanations ;)
No description provided.