Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Supporting dependencies on packages in specific remotes #2495
There have been various comments and requests regarding opam's workflow along a similar theme. This feature request is aimed at addressing these comments.
At the moment, you can share packages in two ways:
Managing a remote is intended for stable released packages, whilst pins are intended for use during development.
However, pins can fall a little short sometimes. In particular, if Alice's package
Of course, Alice could create a new opam remote containing metadata for
The theme of the aforementioned comments and requests is roughly that they like the decentralised workflow of package managers like npm but, due to the above issues, they are unable to replicate that workflow with opam.
As a possible solution, I propose the following: allow dependencies on a package from a specific remote rather than from the remotes installed on the users opam root. So, in the metadata for
I do not have a working knowledge of the semantics of dependencies, remotes and universes in opam -- so I do not know how feasible this is or what would be required -- but assuming it is feasible to give such things a reasonable semantics then I think it would help to address the requests for an "npm-style" model.
An alternative to this suggestion would be to allow direct dependence on packages at a given address rather than via a remote. I think that would work in the small, but keeping a package's metadata separate from it makes the system more robust and remotes are a good way of doing this. Remotes also provide a good focal point for tooling (e.g. automatic generation of documentation containing cross-references between all the packages on the remote).
#2762 has some ideas for handling the same use-case.
Yeah, possibly it's not the right approach. Although I don't see any obvious issues with it.
I'm very keen on promoting people having personal or organisation-based remotes rather than the more ad hoc pinning approaches because I think the separation of packages from their metadata makes things more stable, and because they are a good focus for tooling (e.g. it shouldn't be long before we can automatically generate a documentation page for a whole remote).
I'm not sure I will be able to convince people to sacrifice the convenience of the "pin to a git commit" approaches for these benefits, but I think it is worth investing some effort in making remotes easier to maintain in order to encourage their use.
An alternative to the above proposal might be to have more tools for easily managing a remote. For example, a command for "pulling" from one remote into another might work. So you could just do:
to bring the latest janestreet versions into my remote and allow me to depend on them.