convore.json/groups/python/upgrading-packages-with-pip-and-a-requirements-file/messages.json

[{"user_id": 24931, "stars": [], "topic_id": 16126, "date_created": 1301444761.46, "message": "I'm installing some python packages with pip and a requirements file. If I upgrade any package version in the requirements file, it seems like I have to run pip install --upgrade, which then reinstalls all packages. Is there a better way to do this?", "group_id": 292, "id": 474391}, {"user_id": 4077, "stars": [], "topic_id": 16126, "date_created": 1301445468.879899, "message": "if all the packages have versions (at the version you're at), I think that's how it's supposed to behave actually.", "group_id": 292, "id": 474463}, {"user_id": 4077, "stars": [], "topic_id": 16126, "date_created": 1301445036.1606951, "message": "future installs will respect the new version", "group_id": 292, "id": 474427}, {"user_id": 24931, "stars": [], "topic_id": 16126, "date_created": 1301445411.803467, "message": "Yeah, I guess with an automated deploy, the upgrading of a single package isn't easy to do. I'm limited to pip install and pip install --upgrade. So I was hoping that pip would detect that the same version was already installed and skip it.", "group_id": 292, "id": 474460}, {"user_id": 4077, "stars": [], "topic_id": 16126, "date_created": 1301445552.3906131, "message": "I _think_ a pip freeze >> requirements.txt will freeze it with the versions attached.  But double-check that before committing to it.", "group_id": 292, "id": 474475}, {"user_id": 24931, "stars": [], "topic_id": 16126, "date_created": 1301445733.058368, "message": "Ah, I think I found what I was doing wrong. I had specified something like 'django>=1.2'. pip sees that as satisfying the requirement, and doesn't install it (with 'pip install'). To force pip to go through and update all the packages, you use the --update flag.", "group_id": 292, "id": 474498}, {"user_id": 4077, "stars": [], "topic_id": 16126, "date_created": 1301445025.6554661, "message": "You can change the version number in the requirements file to the version you want, then manually upgrade just that one package.", "group_id": 292, "id": 474425}, {"user_id": 4077, "stars": [], "topic_id": 16126, "date_created": 1301445512.968612, "message": "The catch is in making sure you have versions for all the apps.  'django' isn't valid, but 'django==1.2' would keep it from trying to upgrade for example.", "group_id": 292, "id": 474470}, {"user_id": 4077, "stars": [], "topic_id": 16126, "date_created": 1301445929.0395019, "message": "Yeah, >= is 'at least' that version.  Also, I'm not sure if it considers 1.3 as 'current' yet, but it's definitely  not going to install 1.3 as 1.2 satisfies it, unless you delete django altogether.  Then it might.", "group_id": 292, "id": 474536}, {"user_id": 25337, "stars": [{"date_created": 1301486844.3485579, "user_id": 5778}, {"date_created": 1301493704.005713, "user_id": 2087}], "topic_id": 16126, "date_created": 1301477453.664171, "message": "Slightly OT, but when upgrading a system, I tend to check out into a parallel directory named after the tag, virtualenv it, then pip install into that new directory. I then have a 'current' symlink which I can point to the new version. It avoids both the package upgrade problem, and provides a quick way to swap back to an older version if there's an immediate, earth-shattering problem with the new codebase.", "group_id": 292, "id": 480309}, {"user_id": 24931, "stars": [], "topic_id": 16126, "date_created": 1301502900.9771221, "message": "@danfairs I was doing that, but it made for painfully slow deployments because there were so many packages to install and compile (MySQL--python for instance). What I've ended up doing is to create the new virtualenv, copy the site-packages from the current env, and then run pip install on the new virtualenv, which will upgrade any old packages. This significantly speeds up deployment.", "group_id": 292, "id": 482874}]