5
I have a project Symfony2 with facilities managed by composer, with their respective files composer.json and composer.lock synchronized between my local machine and the production server via git.
It is known that when rotating the command composer update, some checks of machine configurations are done before dependency versions are chosen, since in some cases there are different versions of the same package compatible with different environments.
An example package with multiple versions is symfony/icu, responsible for the internationalisation of Symfony2. The version chosen by composer for this package differs between 1.0.0 and 1.2.0 depending on the existence or absence of the library lib-icu in the machine.
Case 1 - Rotate composer update in the local machine
When I spin composer update in my local machine, that has the internationalization library lib-icu, a file is created composer.lock which refers to version v.1.2.0 of the package symfony/icu.
Problem: the production server does not have the lib-icu library, so when I run composer install from the composer.lock previously generated is returned an error referring to the absence of this library.
Case 2 - Rotate composer update on the production server
If, on the other hand, I execute the composer update in my production server, the automatically chosen dependency of symfony/icu is version v1.0.0 (which works without the lib-icu). In that situation, when implementing composer install everything works right, both on the production server and on my local machine.
How to simulate the production server environment?
My question is, is there any way I can run the composer update on my local machine forcing Composer to use version v1.0.0 of the package symfony/icu, instead of using v1.2.0 based on my machine’s configuration? That is, I want to run v1.2.0 composer update on my local machine, and get the same result I would get if it ran on the remote server, as if on my local machine there was no library lib-icu.
My Komposer.json
{
"name": "symfony/framework-standard-edition",
"license": "MIT",
"type": "project",
"description": "The \"Symfony Standard Edition\" distribution",
"autoload": {
"psr-0": {
"": "src/",
"Application": "app/"
}
},
"require": {
"php": ">=5.3.3",
"symfony/symfony": "2.3.*",
"doctrine/orm": ">=2.2.3,<2.4-dev",
"doctrine/doctrine-bundle": "1.2.*",
"twig/extensions": "1.0.*",
"symfony/assetic-bundle": "2.3.*",
"symfony/swiftmailer-bundle": "2.3.*",
"symfony/monolog-bundle": "2.3.*",
"sensio/distribution-bundle": "2.3.*",
"sensio/framework-extra-bundle": "2.3.*",
"sensio/generator-bundle": "2.3.*",
"incenteev/composer-parameter-handler": "~2.0",
"sonata-project/admin-bundle": "2.2.7",
"sonata-project/doctrine-orm-admin-bundle": "2.2.4",
"sonata-project/easy-extends-bundle": "2.1.3",
"sonata-project/user-bundle": "2.2.0"
},
"scripts": {
"post-install-cmd": [
"Incenteev\\ParameterHandler\\ScriptHandler::buildParameters",
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::buildBootstrap",
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::clearCache",
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installAssets",
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installRequirementsFile"
],
"post-update-cmd": [
"Incenteev\\ParameterHandler\\ScriptHandler::buildParameters",
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::buildBootstrap",
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::clearCache",
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installAssets",
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installRequirementsFile"
]
},
"config": {
"bin-dir": "bin"
},
"minimum-stability": "stable",
"extra": {
"symfony-app-dir": "app",
"symfony-web-dir": "web",
"incenteev-parameters": {
"file": "app/config/parameters.yml"
},
"branch-alias": {
"dev-master": "2.3-dev"
}
}
}
So, the detail is that the package in question is not explicit in my Poser.json. I’ll post it in the question.
– pagliuca
I believe that the
symfony/icube a dependency on one’s ownsymfony/symfony, so I don’t know how to demand a specific version for this case.– pagliuca
Ah, I get it. I would try to include this package explicitly by passing the version you want. Capable of this having priority over the dependency chain that Composer is using.
– bfavaretto
Hmmm, good idea! I’ll test it, and let you know if it works. Maybe the
symfony/symfonycontinue "asking" for version 1.2.0 of the dependency, then we’ll see how Composer will solve it. Well, thanks! I’ll test it here.– pagliuca
@bfavaretto Simple and effective suggestion! I simply added "symfony/icu": "v1.0.0" inside the "require" block of Composer.json and my problem was solved. Write this as an answer that I mark as accepted.
– pagliuca
@Why the tag change? The other one has wiki, and follows the brown ones that we define: http://meta.pt.stackoverflow.com/questions/310/como-trata-tags-em-arvore, http://meta.pt.stackoverflow.com/questions/443/requimos-de-patternica-para-tags-com-mais-de-word
– bfavaretto
@bfavaretto because the right one is "symfony", and not "Symphony". ideal is that we exchange the wiki tags too, because people will look for the right name, agree?
– Rodrigo Rigotti
@rodrigorigotti Okay, I hadn’t noticed the spelling error. In this case the hyphen before the 2 stays or not? It is both version number and part of product name... Take a look at the discussions of the goal that Linkei.
– bfavaretto
@bfavaretto is true, well noted. I had left
symfony2because it’s a very common spelling for the framework, so now I’m in doubt. On the other hand, I will change the tag to stay within the Stack Overflow :) value!– Rodrigo Rigotti