Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enforce version pinning #1967

Open
melange396 opened this issue Jun 1, 2024 · 2 comments
Open

Enforce version pinning #1967

melange396 opened this issue Jun 1, 2024 · 2 comments
Labels
chore devops future-solution Solutions to problems we don't have yet but still dread

Comments

@melange396
Copy link
Contributor

We should probably do some version pinning. It is good for consistency and reproducibility. There is essentially none in this repo, which is dangerous. Having completely unpinned versions risks inadvertent introduction of breaking changes without warning. We were bitten by this when the default cvxpy solver engine changed and produced complications in debugging (see #1966). On the other hand, tight/hard pinning to exact and specific versions can leave us stuck with vulnerabilities or bugs or performance problems that might get fixed without us knowing (dependabot helps with that somewhat though). Also, when everything is hard-pinned, upgrading the version of ONE thing often means youll hafta go find and re-pin updated versions of others for compatibility with shared or dependent packages. Ideally, we could leave versions unpinned for development, and then hard-pin the exact versions as part of release process, but that relies on trusting the unit/integration testing process to expose all breaking changes or new bugs, which isn't a guarantee by any means. So... The best answer is somewhere in between.

Perhaps we should pin our requirements/dependencies to just a particular "minor" version which should allow "patch" revisions for fixes but not introduce breaking changes. We might even consider specifying a strict minimum version along side that.

See also:

@melange396 melange396 added chore future-solution Solutions to problems we don't have yet but still dread devops labels Jun 1, 2024
@melange396
Copy link
Contributor Author

To this end, we may want to get more information about the context of running environments to help us explain and identify discrepancies in performance/behavior/output... We should reexamine #1702 with an eye on the later comments in cmu-delphi/delphi-epidata#987 .

@aysim319 aysim319 pinned this issue Jun 28, 2024
@aysim319 aysim319 unpinned this issue Jun 28, 2024
@melange396
Copy link
Contributor Author

AFAICT, all of the current requirements can be found with this search: https://github.com/search?q=repo%3Acmu-delphi%2Fcovidcast-indicators+path%3Asetup.py+%2F%5Cbrequired+*%3D%2F&type=code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
chore devops future-solution Solutions to problems we don't have yet but still dread
Projects
None yet
Development

No branches or pull requests

1 participant