{"action":"created","issue":{"url":"https://api.github.com/repos/composer/composer/issues/4996","repository_url":"https://api.github.com/repos/composer/composer","labels_url":"https://api.github.com/repos/composer/composer/issues/4996/labels{/name}","comments_url":"https://api.github.com/repos/composer/composer/issues/4996/comments","events_url":"https://api.github.com/repos/composer/composer/issues/4996/events","html_url":"https://github.com/composer/composer/issues/4996","id":138185414,"number":4996,"title":"Allow dependencies to be installed only if needed","user":{"login":"fruitl00p","id":1492861,"avatar_url":"https://avatars.githubusercontent.com/u/1492861?v=3","gravatar_id":"","url":"https://api.github.com/users/fruitl00p","html_url":"https://github.com/fruitl00p","followers_url":"https://api.github.com/users/fruitl00p/followers","following_url":"https://api.github.com/users/fruitl00p/following{/other_user}","gists_url":"https://api.github.com/users/fruitl00p/gists{/gist_id}","starred_url":"https://api.github.com/users/fruitl00p/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/fruitl00p/subscriptions","organizations_url":"https://api.github.com/users/fruitl00p/orgs","repos_url":"https://api.github.com/users/fruitl00p/repos","events_url":"https://api.github.com/users/fruitl00p/events{/privacy}","received_events_url":"https://api.github.com/users/fruitl00p/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2016-03-03T14:01:56Z","updated_at":"2016-03-03T22:45:42Z","closed_at":null,"body":"I'd like for my package to specify dependencies only based on criteria. I.e. I'd like to allow the users of my package to not have to install more than necassary. The situation is as follows:\r\nI'm the maintainer of a package that uses the array_column function. But tor retain as much compatibility as possible i also have to include the dependency for the polyfill ([ramsey/array_column](https://packagist.org/packages/ramsey/array_column)) in order to allow users of old php versions to still install my package. (now this is just an example other polyfill type libraries do exsist) But including this polyfill in newer PHP environments would be silly and only clutter the `vendor/`-stack.\r\n\r\nIs there any way to get composer to ready my package composer.json file and thus only require the dependencies as needed according to the users environment?\r\n\r\nI know this might seem weird, but with the increasing pace of PHP module development i'd like to specifiy my dependencies based on the environment i'm used in. \r\nIt would probably change the `require` flag from a string into an object with more options to specify stuff... \r\n\r\nAn example might be:\r\n```json\r\n{\r\n\t\"name\": \"my-package\",\r\n\t\"description\": \"This is my package that only requires ramsey/array_column when installed in older PHP versions\",\r\n\t\"require\": {\r\n\t\t\"php\": \"5 - 7\",\r\n\t\t\"ramsey/array_column\": {[\r\n\t\t\t\t\"php\":\"5\",\r\n\t\t\t\t\"version\": \"~1.2\",\r\n\t\t]}\r\n}\r\n```\r\nBut one might go as far and specify versions per engine / environment:\r\n```json\r\n{\r\n\t\"name\": \"my-package\",\r\n\t\"description\": \"This is my package that only requires ramsey/array_column when installed in older PHP versions\",\r\n\t\"require\": {\r\n\t\t\"php\": \"5 - 7\",\r\n\t\t\"somepackage/thatrequiresmbstring-sometimes\": {[\r\n\t\t\t\t\"php\": \"5\",\r\n\t\t\t\t\"ext-mbstring\": \"*\",\r\n\t\t\t\t\"version\": \"0.8\",\r\n\t\t], [\r\n\t\t\t\t\"php\": \"7\",\r\n\t\t\t\t\"version\": \"1\",\r\n\t\t]}\r\n}\r\n```\r\nIn this last case the requirement for `somepackage/thatrequiresmbstring-sometime` would depend on both the PHP engine version _and_ if the PHP 5 than also the MBstring extension... \r\n\r\nAny thoughts?\r\n"},"comment":{"url":"https://api.github.com/repos/composer/composer/issues/comments/192002536","html_url":"https://github.com/composer/composer/issues/4996#issuecomment-192002536","issue_url":"https://api.github.com/repos/composer/composer/issues/4996","id":192002536,"user":{"login":"curry684","id":1455673,"avatar_url":"https://avatars.githubusercontent.com/u/1455673?v=3","gravatar_id":"","url":"https://api.github.com/users/curry684","html_url":"https://github.com/curry684","followers_url":"https://api.github.com/users/curry684/followers","following_url":"https://api.github.com/users/curry684/following{/other_user}","gists_url":"https://api.github.com/users/curry684/gists{/gist_id}","starred_url":"https://api.github.com/users/curry684/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/curry684/subscriptions","organizations_url":"https://api.github.com/users/curry684/orgs","repos_url":"https://api.github.com/users/curry684/repos","events_url":"https://api.github.com/users/curry684/events{/privacy}","received_events_url":"https://api.github.com/users/curry684/received_events","type":"User","site_admin":false},"created_at":"2016-03-03T22:45:42Z","updated_at":"2016-03-03T22:45:42Z","body":"The conceptual problem underneath the practical problems is that Composer does not intend to do what you want - lock into a specific environment. Quite the contrary you [are explicitly encouraged to commit `composer.lock` to VCS](https://getcomposer.org/doc/01-basic-usage.md#composer-lock-the-lock-file) as it represents a tried, tested and trusted state of the project and its dependencies. Were we to implement your request it would be a tried, tested and trusted state... assuming a specific PHP version with a specific set of extensions and possibly other stuff like plugins. Making committing the lock practically useless as a production server is never going to expose the exact same environment as your development machine. Meaning the whole point of lockfiles is gone, and you'll never have a consistent state to deploy to production.\r\n\r\nThe weirdest part about this request is actually that the dependent should define this instead of the depender. What would make far more sense is for a package like `ramsey/array_column` to indicate in its own `composer.json` that it's useless in PHP >=5.5, and we could then still mark it as installed but skip it in the autoloader generation, skipping a few CPU and IO cycles on more up to date machines. That feature would benefit [quite a few polyfills](https://packagist.org/search/?q=%22symfony%2Fpolyfill%22) without breaking the locking system.\r\n\r\nTheoretically we already have the syntax partially in place, as for example `symfony/polyfill-mbstring` could `\"provide\": { \"ext-mbstring\": \"*\" }\"`. Implementing that would be quite a lot of effort though just to save a single opcache hit and a single `if` per polyfill, not really worth it."}}