opam is a source-based package manager. It supports multiple simultaneous compiler installations, flexible package constraints, and a Git-friendly development workflow.
This issue is to record a feature request which seems to come up on forums from time to time, and which we've recently had reason to consider in the opam maintainer meeting, but which does not yet seem to have made its way into an issue in this repo.
tl;dr
The opam repository has a gradually expanding set of hoc rules based on --delimited name prefixes. In effect we seem to be imposing a scoping scheme on package identifiers, and opam (and the repository) may benefit from adding explicit support for this functionality.
Symptoms of a problem
We have been using ad hoc means of imposing additional structure and discipline on package naming. E.g.,:
To address namesquating or misleading names, we have added an excessively strict) name collision linting step, and otherwise rely on ad hoc judgement calls from opam repo maintainers. A scoping system could help address this, by following the example of package repositories that support "scopes" or "namespaces" for package identifiers (i.e., npm), that allow packages to be grouped by the individuals or organizations authoring and maintaining them.
Due to historical conventions, the prefix ocaml- has a special, restricted use in the opam repository.
The underlying problem seems to be that package identifiers are atomic, but we actually need them to support a richer structure. We have been hacking this in by convention, but dedicated support for a richer structure may address these (and future) needs in a systematic way.
Prior discussion
This general idea has been discussed before, in at least the following places:
Note that the driving motivation in the linked discussion is to support lowering the bar for publishing packages. This issues does not endorse or request any reduction in curation standards (and this would not be the appropriate repository for that in any case).
I'm not aware of others, but I will expand this list if we find some.
Proposed way forward
No particular solution is proposed here (in particular no concrete syntax or extensions to the CLI or internal data structures). I suggest we use this issue to gather input, and to record a more systematic account of the needs motivating the prior discussions and our emergent practice.
This issue is to record a feature request which seems to come up on forums from time to time, and which we've recently had reason to consider in the opam maintainer meeting, but which does not yet seem to have made its way into an issue in this repo.
tl;dr
The opam repository has a gradually expanding set of hoc rules based on
--delimited name prefixes. In effect we seem to be imposing a scoping scheme on package identifiers, and opam (and the repository) may benefit from adding explicit support for this functionality.Symptoms of a problem
We have been using ad hoc means of imposing additional structure and discipline on package naming. E.g.,:
To address namesquating or misleading names, we have added an excessively strict) name collision linting step, and otherwise rely on ad hoc judgement calls from opam repo maintainers. A scoping system could help address this, by following the example of package repositories that support "scopes" or "namespaces" for package identifiers (i.e., npm), that allow packages to be grouped by the individuals or organizations authoring and maintaining them.
Due to historical conventions, the prefix
ocaml-has a special, restricted use in the opam repository.Follow the example of
conf-, restricted prefixes are being introduced to communicate the function of certain classes of packaged. Following https://github.com/ocaml/opam-repository/pull/25861, we will be adding three new restricted prefixes, supported by new CI logic https://github.com/ocurrent/opam-repo-ci/issues/315The underlying problem seems to be that package identifiers are atomic, but we actually need them to support a richer structure. We have been hacking this in by convention, but dedicated support for a richer structure may address these (and future) needs in a systematic way.
Prior discussion
This general idea has been discussed before, in at least the following places:
Related issues
-delimited prefix.2683 : because this feature would require alteration of supported name schemes
Scopes/namespaces in other packaging systems
I'm not aware of others, but I will expand this list if we find some.
Proposed way forward
No particular solution is proposed here (in particular no concrete syntax or extensions to the CLI or internal data structures). I suggest we use this issue to gather input, and to record a more systematic account of the needs motivating the prior discussions and our emergent practice.
cc @raphael-proust and @kit-ty-kate