{"action":"created","issue":{"url":"https://api.github.com/repos/pypa/pip/issues/2745","labels_url":"https://api.github.com/repos/pypa/pip/issues/2745/labels{/name}","comments_url":"https://api.github.com/repos/pypa/pip/issues/2745/comments","events_url":"https://api.github.com/repos/pypa/pip/issues/2745/events","html_url":"https://github.com/pypa/pip/issues/2745","id":72744104,"number":2745,"title":"pip -r double installs if called also from within setup.py","user":{"login":"johnyf","id":3135273,"avatar_url":"https://avatars.githubusercontent.com/u/3135273?v=3","gravatar_id":"","url":"https://api.github.com/users/johnyf","html_url":"https://github.com/johnyf","followers_url":"https://api.github.com/users/johnyf/followers","following_url":"https://api.github.com/users/johnyf/following{/other_user}","gists_url":"https://api.github.com/users/johnyf/gists{/gist_id}","starred_url":"https://api.github.com/users/johnyf/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/johnyf/subscriptions","organizations_url":"https://api.github.com/users/johnyf/orgs","repos_url":"https://api.github.com/users/johnyf/repos","events_url":"https://api.github.com/users/johnyf/events{/privacy}","received_events_url":"https://api.github.com/users/johnyf/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":8,"created_at":"2015-05-03T04:08:09Z","updated_at":"2015-05-03T21:35:00Z","closed_at":"2015-05-03T04:42:34Z","body":"In a clean `virtualenv`, with:\r\n\r\n- `python` 2.7.9\r\n- `pip` v6.1.1\r\n\r\nthe `requirements.txt`:\r\n```\r\ndd\r\nply==3.4\r\n```\r\nleaves a `site-packages` containing:\r\n```\r\n0 drwxr-xr-x  14 ... ply\r\n0 drwxr-xr-x   7 ... ply-3.4-py2.7.egg-info\r\n0 drwxr-xr-x   7 ... ply-3.6-py2.7.egg-info\r\n```\r\nwith directory `ply` containing files from both v3.4 and v3.6.\r\n\r\nI think that this is caused by a [nested call to `pip` from the `setup.py`](https://github.com/johnyf/dd/blob/1acb7c6a6433ee4304bc44de58e41b21c97938f8/setup.py#L32) of package `dd`:\r\n```\r\npip.main(['install', 'ply >= 3.4', ...])\r\n...\r\nsetuptools.setup(...install_requires=['ply >= 3.4', ...],...)\r\n```\r\nApparently, `pip` collects all requirements, decides to install `ply` v3.4, starts building packages.\r\nWhile building packages, the nested call to `pip` should see no installed `ply`, if all packages are going to be copied at the end to `site-packages` (not sure if this is the behavior of `pip`).\r\nSo the nested call installs `ply` v3.6, satisfying `ply >= 3.4`, because it is oblivious of the requirement `ply==3.4` in the requirements file. In addition, the outer call to `pip` that handles the `requirements.txt` doesn't know that a nested call occurred, so apparently it is going to build and copy `ply` v3.4 on top of the nested install of `ply` v3.6. This leaves a corrupted `ply` in `site-packages`."},"comment":{"url":"https://api.github.com/repos/pypa/pip/issues/comments/98546804","html_url":"https://github.com/pypa/pip/issues/2745#issuecomment-98546804","issue_url":"https://api.github.com/repos/pypa/pip/issues/2745","id":98546804,"user":{"login":"rbtcollins","id":499678,"avatar_url":"https://avatars.githubusercontent.com/u/499678?v=3","gravatar_id":"","url":"https://api.github.com/users/rbtcollins","html_url":"https://github.com/rbtcollins","followers_url":"https://api.github.com/users/rbtcollins/followers","following_url":"https://api.github.com/users/rbtcollins/following{/other_user}","gists_url":"https://api.github.com/users/rbtcollins/gists{/gist_id}","starred_url":"https://api.github.com/users/rbtcollins/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rbtcollins/subscriptions","organizations_url":"https://api.github.com/users/rbtcollins/orgs","repos_url":"https://api.github.com/users/rbtcollins/repos","events_url":"https://api.github.com/users/rbtcollins/events{/privacy}","received_events_url":"https://api.github.com/users/rbtcollins/received_events","type":"User","site_admin":false},"created_at":"2015-05-03T21:35:00Z","updated_at":"2015-05-03T21:35:00Z","body":"With sufficient work we could error if the installed packages have changed during collection. *Any* changed to the package database during collection invalidates all of collection: new additional packages may be conflicting requirements (#2687) or if they satisfy a desired package may have different dependencies of their own (#988) and so we'd at minimum have to perform the entire collection again.\r\n\r\nDealing with other installing tools implies that the locking mechanism should be a distutils PEP and standardised."}}