undefined | Better HN

0 pointsbarbazoo2y ago0 comments

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?

0 comments

4 comments · 2 top-level

EdwardDiego2y ago· 2 in thread

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.

o11c2y ago

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.

EdwardDiego2y ago

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.

linkdd2y ago

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.

j / k navigate · click thread line to collapse