Open gjoseph92 opened 1 year ago
Should hatch be considered? it doesn't yet have lock file support but is under the pypa org and seems to have momentum as PYPA's preferred packaging tool.
I've been really curious about hatch, but
pip install
something in an environment, and forget to add it in tool.hatch.envs.<name>
. AFAIU, hatch doesn't have something like poetry's --remove-untracked
, so you might not realize you'd messed up until you got to CI.Lockfiles to me are the core feature though. I never, ever want to end up with different versions of things installed in different environments (my machine vs another dev's machine vs GitHub actions vs readthedocs vs Binder vs ...).
Hey, creator of Hatch here! Out of curiosity, why does this library need lock files?
@ofek good question.
Currently, this project uses lockfiles to reproduce the environment:
Technically, we actually just reproduce subsets of the environment in different places via dependency groups (docs deps aren't installed on binder, etc.)
Broadly, I think there are two related but separate problems:
I wouldn't mind having two separate tools for these separate problems, if the ergonomics were as easy as Poetry/PDM/any modern CLI-based locking package manager. To me, hatch just focuses on problem 1; I don't know of a tool that focuses solely on problem 2 (besides pip freeze
I guess, which does't meet the ergonomics requirement). Because these are pretty tightly related (if I change the rasterio
dependency in stackstac, I also want to change the rasterio
pinned in my environment), most tools (poetry/pdm/npm/cargo/etc.) seem to solve them together.
But I care a lot about problem 2—quite a bit more than I care about problem 1, actually. I have been bitten so many times by un-pinned dependencies changing, and a new release on PyPi of some transitive dep breaking builds. To me, having a lightweight, declarative process to ensure a consistent Python environment everywhere is key to a modern development experience, where you're needing to re-create that environment all the time in many places in an automated way.
I just switched to PDM, because Poetry was taking multiple hours to lock dependencies (due to Coiled being a dependency with way too many transitive deps, and https://github.com/python-poetry/poetry/issues/5121).
Testing with Poetry 1.2.0 though, the situation doesn't seem as bad.
Poetry is still 2x slower than PDM—170 seconds instead of 42. But 170s is way, way better than 3h. It's within the range of tolerability. And since Poetry is more widely used and mature than PDM, and a bit more straightforward to work with in virtualenvs, I'm tempted to stick with it for now, even with the longer lock times. It still doesn't have https://github.com/python-poetry/poetry/issues/697, which could end up being critical at some point, but so far hasn't been too much of an issue.
Probably won't take any action on this for now, just noting this in case other compelling reasons come up one way or another.