-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Big new year cleanup #11194
Big new year cleanup #11194
Conversation
This is probably not to be merged as is, but may be useful to open some discussions, and make some benches and tests. What this patch does is remove any package that - has a version in the form 'MAJOR.MINOR.PATCH' - is the non-latest patch revision of the non-latest minor revision In other words, we keep only the latest patch revision of all versions but the current one. For example, if you have 1.1.0, 1.2.1, 1.2.2, 1.3.0 and 1.3.1, only 1.2.1 will be removed.
✅ No new or changed opam files daca426❗ Installability check (8157 → 6439)
|
Interesting fact that this removed 17 packages that were already not installable :) And this is very rough in many areas. For example, quick testing revealed like |
That sounds like a nice thing to do ! ❤️ |
I definitely think these should not be deleted, but moved to another opam remote (with the git history) for archival. This way patch releases can be accessed if necessary for historical releases. |
TBH I'm not sure which way is easier: (a) trying to figure out which bits and pieces to remove from the main opam-repository and leave everything in place (b) start a new repo from scratch with (1) opam 2.0 and (2) ocaml 4.06 and start an initially empty repository, pick only libraries which are requested (and have 4.06 support) in their latest release. at point X, switch X to opam-repository and archive opam-repository. certainly we can also move forward with removing patch releases, but since there is no common semantic versioning, some packages may introduce (as discovered by altgr) new dependencies / bump ocaml support / ... maybe in the same effort of (b) we could formulate properties on how to get your package into that well-maintained repository (maybe code coverage? documentation has to exist? mirage/mirage-www#562 has a list of ideas from the mirage community). I'm still not sure whether (b) is a good goal, but certainly getting rid of releases is worthwhile in the long run. i'm working on reviving the opam-signing effort and my plan for getting this up and running is to collect experience with a small repository, before scaling up to the main repository... |
I like (b), it would provide a great deal of cleanup and start enforcing some minimal good practices. In that case I'd also suggest to split the packages in alphabet sub-folder ( |
I am not against a separate curated repository, but I think the goals diverge, as it would take a very long time to replace the current repo. As for the cleanup itself: yes, I didn't really expect the above approach to work, but wanted to see how it would fare. Another, more complicated way would be, instead of just looking at version numbers, to check package relationships. For example, we may be able to define equivalent versions of a package (same dependencies, no dependent packages discriminate between the two versions), and keep only the max of every equivalence class. Another, completely different approach would be to look at opam.ocaml.org's logs and kill any older version that hasn't been used in the past month or so. And any combination could work, like the semver approach, while keeping packages with enough liveness (and their dependencies). |
opam 2 has a few fallback strategies, including ditching the version constraints when they can't be satisfied. |
I'll close this PR until we reach consensus on the right way to handle this. It's overloading the CI. |
Rather than splitting up the repository, maybe it would be better if opam supported masks? The idea is that any masked package versions would be filtered out before dependency analysis and CI testing, so they would not contribute to the complexity. Examples of masked would be
CI test could check that any package versions includes at least the masks of its dependencies. This would involve work on both opam and CI, though we might save work in moving packages between repos. |
This is probably not to be merged as is, but may be useful to open some discussions, and make some benches and tests.
What this patch does is remove any package that
In other words, we keep only the latest patch revision of all versions but the current one.
For example, if you have 1.1.0, 1.2.1, 1.2.2, 1.3.0 and 1.3.1, only 1.2.1 will be removed.