Move OpamSWHID and its dependency towards the swhid_core library from opam-core to opam-format - #6415
Draft
kit-ty-kate wants to merge 1 commit into
Draft
Move OpamSWHID and its dependency towards the swhid_core library from opam-core to opam-format#6415kit-ty-kate wants to merge 1 commit into
kit-ty-kate wants to merge 1 commit into
Conversation
… opam-core to opam-format
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a starting point for a broader discussion about the goal of each opam libraries and in particular
opam-core.In my opinion
OpamSWHIDisn't really useful outside of the context ofopam-formatand moving it there allows us to avoid an unnecessary dependency towardsswhid_corein `opam-core.However we can also question ourselves on whether
opam-coreitself is a useful library to have on its own. As far as i know, no-one uses it without also usingopam-formatso maybe merging the two could be envisioned.Another question could also be "what is our threshold for generic things to put into opam-core vs. the other library?". For example #5892 leaves
OpamSystem.patchwhere it was but now a new dependency is required, but this function is only used inopam-repositoryso it could be better to just move it to that library instead.So far after thinking about it a little i'm thinking that we could merge
opam-coreintoopam-formatthen that leaves:opam-clientfor UI and commands stuffopam-statefor the low-level internalsopam-repositoryfor things related to fetching and repository compositionopam-solverfor solver stuffopam-formatas a base (format and all the generic modules)