Replies: 1 comment
-
Thanks for bringing this up @nielstron. Logically, I agreed that having version capping will cause more problems than it avoids. Let me try to remove them in a branch and see if there is any major issue practically. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Version capping refers to restricting the upper bound of dependencies. I maintain the OpShin and uplc package with both rely on pycardano and also use similar version capping as pycardano using Poetry. Maybe you also noticed this, but setting up new projects this way can be incredibly painful.
A more lenghty explanation for why this is the case is written down in this nice blogpost: https://iscinumpy.dev/post/bound-version-constraints/
But essentially my issue is that every small new release in, say, downstream uplc, requires a number of version bumps in OpShin and intermediate packages as well. It gets worse when users are trying to mix and match versions of other maintainers that are not in sync with these versions. And most of the time this is entirely unnecessary, because nothing actually breaks.
Regarding reproducibility: I still recommend to use Poetry and keep the poetry.lock file + CI to track which exact versions of libraries are known to play well together. IMO (and agreeing with the blogpost above) it would then be a simple fix for the end-user to pin whichever library broke for them to the exact version they need. All the capping however very frequently leads to unhealable fixes if there is no version bump in between.
So I suggest to remove version capping in PyCardano, the OpShin packages and Ogmios. Please let me know what you think, especially @cffls and @wrmarchetto
Beta Was this translation helpful? Give feedback.
All reactions