7 ms·

Pip-Tools is great for pinning and freezing with hashes. Does what it should. So much faster than pipenv or poetry. Never looked back.

wyuenho 4y ago
You still need something else to manage your python versions and virtualenvs tho, and then as soon as you've pick a solution for the latter two problems, chances are you'll discover these tools also have a lock files that'll solve the problem of freezing packages and enabling reproducable builds for you.
- kroolik 4y ago
  What about just throwing every thing into docker?
  - orzig 4y ago
    Docker is good at what it is good app, but sometimes I don’t want to deal with a whole other system just want to share code with five coworkers
  - wyuenho 4y ago
    That would be the "something else" :) If you don't want to fire up docker, you'll have to look elsewhere other than just pip-tool
epage 4y ago
Until you need a platform or Python version agnostic lock file. pip-tools compiles the list for your current environment which makes it limited.
- orzig 4y ago
  This is interesting; can you expand or point to some documentation? I don’t have this design requirement right not, so I’m trying to understand any growing pains I might be locking myself into
  - jrib 4y ago
    Not OP, but in our case, there was a package that had a dependency for python3.6 but not for python3.8. Our production environment was python3.6. Devs rebuilt the requirements.txt with python3.8. When we attempted to use the requirements.txt with python3.6, we couldn't because a package was missing (and we installed with `--require-hashes`). The dependency was `importlib-metadata` iirc. But googling around, here's an example of a package that has dependencies that changed based on the python version: https://github.com/pypa/pep517/blob/main/pyproject.toml#L13 https://github.com/pypa/pep517/blob/main/pyproject.toml#L13 . In our case, we just made sure to rebuild the requirements.txt with the version that matched our production; not sure if there's a "nice" way to support multiple versions with pip-tools.
    - sinsterizme 4y ago
      As you discovered, the actual fix is making sure your production and development python environments match. As for platform discrepancies, docker helps with this
- BerislavLopac 4y ago
  > platform or Python version agnostic lock file I might be splitting hairs here, but this seems like an oxymoron: if it's agnostic on anything, it's not really a lock file.

wyuenho 4y ago

You still need something else to manage your python versions and virtualenvs tho, and then as soon as you've pick a solution for the latter two problems, chances are you'll discover these tools also have a lock files that'll solve the problem of freezing packages and enabling reproducable builds for you.

kroolik 4y ago
What about just throwing every thing into docker?
- orzig 4y ago
  Docker is good at what it is good app, but sometimes I don’t want to deal with a whole other system just want to share code with five coworkers
- wyuenho 4y ago
  That would be the "something else" :) If you don't want to fire up docker, you'll have to look elsewhere other than just pip-tool

epage 4y ago

Until you need a platform or Python version agnostic lock file. pip-tools compiles the list for your current environment which makes it limited.

orzig 4y ago
This is interesting; can you expand or point to some documentation? I don’t have this design requirement right not, so I’m trying to understand any growing pains I might be locking myself into
- jrib 4y ago
  Not OP, but in our case, there was a package that had a dependency for python3.6 but not for python3.8. Our production environment was python3.6. Devs rebuilt the requirements.txt with python3.8. When we attempted to use the requirements.txt with python3.6, we couldn't because a package was missing (and we installed with `--require-hashes`). The dependency was `importlib-metadata` iirc. But googling around, here's an example of a package that has dependencies that changed based on the python version: https://github.com/pypa/pep517/blob/main/pyproject.toml#L13 https://github.com/pypa/pep517/blob/main/pyproject.toml#L13 . In our case, we just made sure to rebuild the requirements.txt with the version that matched our production; not sure if there's a "nice" way to support multiple versions with pip-tools.
  - sinsterizme 4y ago
    As you discovered, the actual fix is making sure your production and development python environments match. As for platform discrepancies, docker helps with this
BerislavLopac 4y ago
> platform or Python version agnostic lock file I might be splitting hairs here, but this seems like an oxymoron: if it's agnostic on anything, it's not really a lock file.