Add poetry.lock file

[siraben]

Please add the poetry.lock file to ensure reproducibility.

[rschroll]

It seems to me that a lock file doesn't really help, and may actually hurt, things for a library. pip knows nothing about the lock file, so anyone installing the library in the standard way will get whatever package versions pip's solver comes up with. Committing the lock file would therefore only ensure that all developers are using the same versions. Thus, only users would discover version incompatibilities, which is the opposite of what we want.

If I'm missing something, please elaborate on the problem that this would solve.

[bqv]

Reproduciple builds. The lock file (in every popular language, not just python) is there to ensure users can reproduce a known-to-work configuration of dependency versions, and in @siraben 's case allow nix to build this without straight-up guessing at versions that might work.

That it is too restrictive is an absurd argument, anyone bothered by it can delete it effortlessly, creating one is however nontrivial. You should add one.

[rschroll]

I understand the point of reproducible builds. I also understand that the poetry.lock file has no impact on the build process. This is easy to test: Delete any existing virtual environment, and run poetry build. It will create a new virtual environment with only those package necessary for the build: pip, setuptools, and wheel. It is these packages, along with poetry and Python itself, which need to be version locked for reproducible builds. But none of these are specified in the poetry.lock file. (Of course, with a little thought, this is obvious. Poetry is designed to work with multiple Python versions via pyenv, so system-level versions wouldn't be included in the .lock file.)

The poetry.lock file

• does not ensure reproducibility for installations through pip;
• does not ensure reproducibility for builds;
• decreases diversity in development environments, possibly hiding version conflicts that those installing not from source will run into.

Its role is to provide reproducible development, testing, and deployment environments. As rmrl is a library, I see these first two as undesirable (see above) and the last as irrelevant. (If I ever get around to setting up CI testing, I may well change my mind on one of these.)

If you are to achieve reproducible builds for nix, it will be by locking versions of Python, poetry, setuptools, etc. And I'm sure you'd lock that to a fixed value for all packages, and not take whatever versions a thousand Python developers happen to have installed on their machines.

creating one is however nontrivial.

If poetry install ever fails to assemble a working poetry.lock file, I consider that a bug in rmrl. Please report it! (And if you consider typing these 14 characters to be nontrivial, well, "absurd" springs to mind....)

[rschroll]

Closing for now. I'm happy to entertain adding a lock file if there's another use case where it would be beneficial.