> Looking upwards to a `.opam` directory and use it as opam root would be > straightforward to implement (well, I'd just have to copy-paste some code > from > ocp-indent). But I don't think it is a good idea: > 1. it duplicates lots of stuff, including synchronising repositories, caches, > and compiling OCaml > 2. does it replace ~/.opam or add to it ? > 3. how about `opam config env` ? Should you ensure to run it after you cd to > your project ? Sounds dangerous, but it might be handled by the build system. > 4. and what about tools such as merlin ? You surely won't install them within > every project...
I think the idea of a local .opam is to fully replace the global one, so all the state is associated to the project directory. I think having a global .opam directory to be used as a cache should be an "implementation detail", as a cache where you can store and symlink stuff if needed. You can do similar tricks with Git and share a global block store, but the user only think about distinct "repositories". > Another big question is that we otherwise need build systems to be > opam-aware. > Without interfering when they are run from within opam, of course. Guess I'll > get back to working on opam-as-build-system ;) Having a way to optimally configure opam and a build system to work together is certainly a good idea of evolution... Thomas _______________________________________________ opam-devel mailing list [email protected] http://lists.ocaml.org/listinfo/opam-devel
