-
Notifications
You must be signed in to change notification settings - Fork 165
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
OPAM files in extra-dev vs. upstream repository #995
Comments
Does it work for dependencies? What do you mean by "hosting url"? As far as I know, the development packages are mainly used for two things:
|
Developers can update their OPAM file rapidly and possibly forgot to merge changes here, making the configuration here outdated, including dependencies and build processes. If we only store a URL and let user fetch the latest configuration through that URL, that might solve the problem. |
If developers submit their OPAM files here, we can at least review them and correct mistakes and minor flaws. With only an URL, we can't really ensure anything, and any changes would have to be approved by upstream repo maintainers. Therefore, I'm against storing only URLs. We are actively using the extra-dev repo and its metadata for finding and analyzing Coq projects for proof engineering research. Only storing URLs would be a big hindrance. |
@liyishuai for the record, I think the problem mentioned here (discrepancy between upstream It may even be a good idea to keep this issue open as a reminder. |
I'm not familiar with Dune; it'll be nice to have that solution. |
FWIW, here is a somewhat related issue: #954. |
We can already track GitHub repos with
opam pin https://github.com/user/repo.git
.Is it still worth maintaining a (very likely outdated) OPAM file in extra-dev?
Should we host only the URL, from which to fetch all other OPAM configurations?
The text was updated successfully, but these errors were encountered: