[opam-devel] Ideas from Node.js

[Thomas Gazagnaire]

>  Instead of three files "descr", "opam" and "url" they have just one "package.json" file.
> 
>  They directly use the JSON syntax to describe the packages. The syntax is heavier than the one of "opam" files so the advantage is not clear, but this syntax is already known by most programmers / text editors, easily described with a JSON schema and can be parsed by any programming language.

I've already explained the current design in [1]. Again, the current design is not perfect but I am not really convinced by having a fully JSON-compliant format. However, I you think that's important, feel free to send us patches to add a new supported format and we can discuss how to integrate it properly.

>  Finally, the "package.json" file is located at the root of the sources of a project. This is a more self-contained approach. Someone can even install a package giving the repository Git's url, without registering it on a repository.

This is done on purpose: package metadata are supposed to change often (because you don't really control the release cycle of libraries a given package depends on) -- if you want to fix a version constraint or if you want to add missing configuration options -- so metadata are better stored in a different place than the package contents (otherwise you have to make a release for every metadata change). Moreover, it let you fix package descriptions when new metadata appear (the best example is the "new" 'depext' field that we will start to populate quite soon in all the already existing packages).

However, for packages being developed, I understand it is more flexible to have both metadata and contents in your package tree. This is not yet possible with OPAM, although you can add an 'opam' file at the root of any pinned package and it will be used instead of the one in the metadata repository. See for instance [2]. The way I would go with this would be to create a local repository with all your dev packages and do what you want with them, but I agree that what you ask could make the life of package developer easier. I'm opening [3] to keep track of that.

--
Thomas

[1] https://github.com/OCamlPro/opam/issues/884
[2] https://github.com/OCamlPro/opam/issues/671
https://github.com/OCamlPro/opam/issues/941