4 ms·

> There's "pip freeze" but that's a one-time operation that you can't then reverse, so it's only usable for leaf applications. What do you mean by reverse? You

> There's "pip freeze" but that's a one-time operation that you can't then reverse, so it's only usable for leaf applications. What do you mean by reverse? You can certainly upgrade all packages locally and then run pip freeze again if you want to set up newer versions, or like manually change versions in your requirements.txt and `pip install --upgrade` to update them. For stronger reproducibility guarantees there's also `--require-hashes`, although admittedly freeze doesn't appear to support easily writing hashes to a requirements.txt. > per the previous point, it probably won't come out the same as before. I don't see how this follows. If you have frozen dependencies, it will. > You're supposed to use pip to manage which python version each project is using. But you're supposed to use the installer for it that's distributed with the python runtime. But only certain versions of the python runtime... No you use venv for that. Venv which has been available since python 3.3, in 2012, and on pip, ensurepip has been since 3.4, in 2014. If you're using a version of python that's 10 years old, I don't really know what to say. > There's only one global repository. If you want to build some libraries and reuse them the same way you'd use a normal library dependency, you have to publish them to the global PyPi. I think there might be an expensive service that works around this, but there's no repository program that you can just spin up on your own servers. I mean you can install from git directly: https://pip.pypa.io/en/stable/topics/vcs-support/#vcs-support https://pip.pypa.io/en/stable/topics/vcs-support/#vcs-suppor..., and there is documentation on spinning up a local repository (which for packages, is just files in a known directory structure): https://packaging.python.org/guides/hosting-your-own-index/ https://packaging.python.org/guides/hosting-your-own-index/

lmm 5y ago
> What do you mean by reverse? You can certainly upgrade all packages locally and then run pip freeze again if you want to set up newer versions, or like manually change versions in your requirements.txt and `pip install --upgrade` to update them. For stronger reproducibility guarantees there's also `--require-hashes`, although admittedly freeze doesn't appear to support easily writing hashes to a requirements.txt. You need to know, and maintain, both what you intended to depend on and what you physically ended up depending on. So in more sensible ecosystems you will have, e.g., Gemfile and Gemfile.lock. pip freeze is, effectively, the way you create Gemfile.lock, but it forces you to destroy Gemfile to do it. And so you can't really use it.
- dragonwriter 5y ago
  > So in more sensible ecosystems you will have, e.g., Gemfile and Gemfile.lock. pip freeze is, effectively, the way you create Gemfile.lock, but it forces you to destroy Gemfile to do it. No, it doesn't. pip freeze -r requirements.txt > requirements.lock.txt There's plenty of legitimate criticism of python in general and pip in particular, but much of yours send to be criticism of things that are factually untrue.

lmm 5y ago

> What do you mean by reverse? You can certainly upgrade all packages locally and then run pip freeze again if you want to set up newer versions, or like manually change versions in your requirements.txt and `pip install --upgrade` to update them. For stronger reproducibility guarantees there's also `--require-hashes`, although admittedly freeze doesn't appear to support easily writing hashes to a requirements.txt. You need to know, and maintain, both what you intended to depend on and what you physically ended up depending on. So in more sensible ecosystems you will have, e.g., Gemfile and Gemfile.lock. pip freeze is, effectively, the way you create Gemfile.lock, but it forces you to destroy Gemfile to do it. And so you can't really use it.

dragonwriter 5y ago
> So in more sensible ecosystems you will have, e.g., Gemfile and Gemfile.lock. pip freeze is, effectively, the way you create Gemfile.lock, but it forces you to destroy Gemfile to do it. No, it doesn't. pip freeze -r requirements.txt > requirements.lock.txt There's plenty of legitimate criticism of python in general and pip in particular, but much of yours send to be criticism of things that are factually untrue.