Pip is fine, it depends on your goals. I've found requirements.txt less enjoyable to maintain for several reasons – you need to separate dev, test dependencies on your own time, there's no notion of a lockfile for transitive dependencies (`pip freeze` notably doesn't separate actual dependencies from transitive dependencies). pip is also darn slow at installing dependencies once you hit a certain scale, and poetry outperforms it pretty substantially.
Poetry does I expect a package manager to do, and does it well, especially when working with a team of developers on an application versus individually. There's not a compelling reason for me to use pip directly as a less functional alternative.
Bit rot, "it works on my machine"-style issues, cache misses on dependency installation (which can really bloat deploy times in deploy pipelines by busting Docker caches across machines, too). Can be a security issue if a vulnerable library version is pushed and one installs it as a consequence of having non-locked dependencies, especially in python where package install scripts have a lot of power.
Lock files help solve for these. You can build software without solving them, but it makes my life easier.
All of this. Plus picking up a legacy project from someone with a giant requirements file and then trying to pick through and work out what we actually want locked and what's been installed by something deep in a dependency tree is a nightmare. Even if you don't use poetry for your own sake, use it for everyone else's.
Good question! From a template repo commit at work[1]:
Advantages:
- Separates development and production dependencies.
- The dependency version is specified separately from the lock file. In
practice this means that the version in pyproject.toml generally only
needs to be set to anything other than asterisk if and when it becomes
necessary to use a specific version range.
- The lock file includes SHA-256 checksums by default, and these are
checked during installation.
Disadvantages:
- More complex configuration than Pip.
- Python package managers come and go, and this one is likely going to
suffer the same fate eventually.
- Introduces poetry.toml simply to specify that the virtualenv should be
in the project directory. The default is to put virtualenvs in
~/.poetry, which is a non-standard location and therefore might
interfere with typical IDE setups, mounting the virtualenv in containers
or VMs, and the like.
> The dependency version is specified separately from the lock file.
That. The simple fact that a Pip file mixes both the packages you want and the dependencies required by this package, is a valid reason to switch to Poetry IMO.