mlem
mlem copied to clipboard
iterative
Pin all the dependencies
Currently, most of the mlem dependencies aren't being pinned to exact versions, and some of them aren't being pinned at all. Because of this, mlem can and will[^1] break unexpectedly.
Consider using a dependency lock file (e.g. poetry.lock) or manually pinning all the dependencies on setup.py if that makes more sense.
[^1]: As it did today, and will remain broken until https://github.com/iterative/mlem/pull/349 is released; typer wasn't pinned, and the last release included expected breaking changes.
Yes, MLEM will break from time to time with no limitations. Also curious why DVC doesn't limit upper versions for install_requires. cc @skshetry
MLEM is a library, so we need to maintain limitations to be as broad as possible. To my knowledge, this means we need to keep lower and upper bounds for each library. Do you know some holistic way to find out lower and upper limits, @0x2b3bfa0? I guess that includes taking a package, installing all versions, and figuring out which ones let MLEM work. Then repeat for all packages. Doing this from time to time, we could get the exact bounds for each package.
We deliberately dont pin exact version because of what @aguschin said. I set upper bounds for some of them, but this does not guarantee there will be no errors like that. It makes sense to set upper bounds for major versions, but sometimes maintainers break compatibility even in minor releases. I don't know what is the best approach here - set upper bounds, update them with renovate and hope everything will work or just fix errors as they come
If you want to constrain versions as loosely as possible, you may want to follow https://semver.org sanity guidelines: e.g. major version 0 means that a minor version bump can include breaking changes.
Reposting a link shared by @skshetry: https://iscinumpy.dev/post/bound-version-constraints/#tldr Considering everything, I think we're closing the issue as won't fix.