4 ms·

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

by linkdd 3y ago

barbazoo 3y ago
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?
- linkdd 3y 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.
- EdwardDiego 3y ago
  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.
  - o11c 3y 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.
    - EdwardDiego 3y 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.
lmm 3y ago
> 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++)

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

by linkdd 3y ago

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

barbazoo 3y ago

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?

linkdd 3y 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.
EdwardDiego 3y ago
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.
- o11c 3y 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.
  - EdwardDiego 3y 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.

lmm 3y ago

> 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++)