4 ms·

> Packaging your app for running in production, `pip freeze > requirements.txt` and `pip install -r requirements.txt` is the "official solution", it works well

> Packaging your app for running in production, `pip freeze > requirements.txt` and `pip install -r requirements.txt` is the "official solution", it works well enough. It doesn't though. The default format for requirements doesn't specify which requirements are top-level and which are not. Updating dependencies on a project that doesn't have this distinction is complete pain. It also doesn't work when "production" might mean different environments with different Python versions. > Packaging a lib for public distribution, setuptools... I don't have enough experience there but not many people need to actually use it. Actually, using setuptools and setup.py (or a modern equivalent) is very helpful for packaging scripts and commands, defining top-level dependencies or other things. It's much easier to distribute a wheel file to production than a full repository.

samwillis 4y ago
Fair enough, I actually do `requirements.txt` and `requirements-freeze.txt` for top level and then everything. But honestly it works very well.
- gjulianm 4y ago
  Most of the tools you mentioned appeared precisely because the basics with Python don't work that well. I had a project that started similarly, and in the end I had to use to pip-tools to actually separate top-level requirements and lockfiles for different "flavors" of the package (production and dev dependencies, for example). For new projects I would seriously consider poetry because it manages those two concepts directly. There's also the problem of changing requirement files and the environment not being updated to match 1-to-1 the files, either because someone installs something to test and doesn't put it in the requirements file or because you get an updated file from a coworker and forget to run the update. Even then, pip will not delete packages that it doesn't find on the files. It's a mess once you start digging a bit, Python dependency management is extremely basic. It's no wonder why alternative tools appear, they're not redundant, they actually fix pain points in the default tools.
  - samwillis 4y ago
    Completely with you, in complex projects the tooling can be improved and those tools attempt to do that. However going back to what the OP was suggesting about how the situation puts them off using Python, I do think it's the messaging around this that's the problem. Python, the community, need to unify on a message around official tools. There will always be edge cases, but the noise generated by them can give the impression the ecosystem is broken when it really isn't.
rbanffy 4y ago
> It doesn't though. The default format for requirements doesn't specify which requirements are top-level and which are no Shameless plug: you can `pip install pip-chill && pip-chill > requirements.txt` and work as usual. If you feel brave, you can `pip-chill --no-version > requirements.txt` and check if your thing works with the latest of everything.
quacker 4y ago
> It doesn't though. The default format for requirements doesn't specify which requirements are top-level and which are not. Updating dependencies on a project that doesn't have this distinction is complete pain. It also doesn't work when "production" might mean different environments with different Python versions. This is why (imo) you should include immediate dependencies in setup.py install_requires, and use requirements.txt for the "lock file" that contains all dependencies.

samwillis 4y ago

Fair enough, I actually do `requirements.txt` and `requirements-freeze.txt` for top level and then everything. But honestly it works very well.

gjulianm 4y ago
Most of the tools you mentioned appeared precisely because the basics with Python don't work that well. I had a project that started similarly, and in the end I had to use to pip-tools to actually separate top-level requirements and lockfiles for different "flavors" of the package (production and dev dependencies, for example). For new projects I would seriously consider poetry because it manages those two concepts directly. There's also the problem of changing requirement files and the environment not being updated to match 1-to-1 the files, either because someone installs something to test and doesn't put it in the requirements file or because you get an updated file from a coworker and forget to run the update. Even then, pip will not delete packages that it doesn't find on the files. It's a mess once you start digging a bit, Python dependency management is extremely basic. It's no wonder why alternative tools appear, they're not redundant, they actually fix pain points in the default tools.
- samwillis 4y ago
  Completely with you, in complex projects the tooling can be improved and those tools attempt to do that. However going back to what the OP was suggesting about how the situation puts them off using Python, I do think it's the messaging around this that's the problem. Python, the community, need to unify on a message around official tools. There will always be edge cases, but the noise generated by them can give the impression the ecosystem is broken when it really isn't.

rbanffy 4y ago

> It doesn't though. The default format for requirements doesn't specify which requirements are top-level and which are no Shameless plug: you can `pip install pip-chill && pip-chill > requirements.txt` and work as usual. If you feel brave, you can `pip-chill --no-version > requirements.txt` and check if your thing works with the latest of everything.

quacker 4y ago

> It doesn't though. The default format for requirements doesn't specify which requirements are top-level and which are not. Updating dependencies on a project that doesn't have this distinction is complete pain. It also doesn't work when "production" might mean different environments with different Python versions. This is why (imo) you should include immediate dependencies in setup.py install_requires, and use requirements.txt for the "lock file" that contains all dependencies.