@gasche: Travis is now complaining about + in the compiler version. I suspect that manual intervention is indeed required for a PR to show up as an OPAM compiler.

On the other hand, you can easily install any development repository as an opam switch by using my script opam-compiler-conf. Once it is in your $PATH somewhere:

git clone https://github.com/gasche/ocaml
cd ocaml
git checkout ocamldep-paths 
opam compiler-conf configure
make world.opt
opam compiler-conf install

(That is, of course, less convenient than the semi-official switches if you want other users to test it.)

Yes, there's always the manual option, but OPAM has spoiled me... ;-)
I don't know who's in charge of blessing a new OPAM switch -- @avsm perhaps?

I've adapted libfoobar to use OCamldep's new -paths option. It works as expected, though this is a very simple example.

I would like to take a shot at porting the more realistic Lambdoc oasification branch, though since many of its dependencies do not compile out-of-the-box with 4.03, it may take a while. (Alternatively, I may opt to complexify Libfoobar, mimicking the structure of Lambdoc but without introducing any external dependencies.)

It should be trivial to backport the patch to the 4.02.1 branch to test on your code. Just ask if there is a conflict I can't think of right now, or if you don't feel comfortable enough with git to do it yourself.

@darioteixeira about the Travis build, that is/was a bug in OPAM, which should be fixed now (see OPAM#1999).

I've just uploaded new PPA snapshots of OPAM 1.2.1dev, so I'll submit a pull request to OCaml's Travis setup to use them once they've uploaded. That should fix the CI here.

Just an update on my progress on this front:

Instead of backporting the compiler changes to 4.02.1 or complexifying libfoobar, in the end I've opted for a different solution to test -paths in a "real" project: I took the oasification branch of Lambdoc and pruned away the bits that had external dependencies not compilable with 4.03. The resulting ocamldep-paths branch is mutilated and disfunctional, but that hardly matters since we just need it for testing the build system.

Anyway, though compilation from scratch works. Incremental compilation sometimes fails with an "inconsistent assumptions" error. This means there are still some corner cases I haven't considered and I'll have to take a closer look.

In related news, I went for a mixed approach in the oasification branch proper: I use module aliases and no-alias-deps only for referring to "packs" below on the dependency hierarchy. Within each hierarchical level I don't rely on this mechanism, which means the code compiles fine on 4.02 without any special tricks to avoid circular dependencies. Though this approach requires declaring module aliases on each module for intra-hierarchy references and is thus a bit more cumbersome, it's not too cumbersome because shortcuts can be used for inter-hierarchy references. It's not perfect, but it does have the advantage of being straightforward to understand and not requiring any dirty tricks postprocessing the output of OCamldep.

Just a heads-up: the oasification branch of Lambdoc is the new master, and I've deleted the old branch.

I've relaunched the Travis build but it's still failing and I don't understand why.

@gasche Can you please decide what to do with this one? It's been unloved for 18 months.

Still no comment for nearly another 3 months, so closing. This can always be reopened if someone has the time to work on it.