Hacker News Reader

Comment by linkdd | Hacker News Reader

Of this specific solution yes, of the "ecosystem" no. This has been solved by many other solutions (pipenv, poetry, pdm, etc...).

View on HN

> This has been solved by many other solutions (pipenv, poetry, pdm, etc...).

It's been repeatedly not solved by the new tool the Python ecosystem comes up with every few years, IME. (It reminds me of an old quote I can't find about how every new version of C++ contains new features to fix the problems with the new features in the previous version of C++)

I haven’t tested this yet but what’s better about pipfile.lock over whatever pip-compile spits out? It sounds like both are exact versions of packages, no?

Pipfile.lock is broken if you have wheels wrapping compiled code as it captures the arch in the lock file! Poetry doesn't do this, so you can lock on your M2 Mac and install on x86 fine.

Pip-compile in the most common use just creates a requirements.txt with everything pinned to a given version.

I think you can do hash stuff with it, but haven't used that part.

If you're building for multiple platforms, it doesn't make sense to lock your dependencies.

"Some platforms need newer versions" is the default case; don't make your tools fight it.

That said, package managers that do timestamp-based version filtering would be very useful.

Eh? We're locking the version of the dependency, we don't need to look the particular compiled version of it, because they only differ in which architecture they were compiled for. We want 3.2.0 of dep_x on ARM and on x86_64, the last thing we want is running different versions of a dependency in different environments, that way lies madness.

I don't know about pipfile.lock nor pip-compile, once I tested poetry I stuck to it without rethinking it (because I have better things to do than test all the package managers out there).

But the poetry.lock contains hashes as well.

Reply on news.ycombinator.com