Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Towards an `OCAMLPATH` #8898
Most programming languages have a notion of include path to allow to specify relative file lookups in an ordered sequence of absolute install directories. For example there is
OCaml has this but in a very limited form via the
I would like to propose to extend the semantics of this notation in a backward compatible way to support lookup in a proper
This would be a first step towards eventually providing better library lookup in the compiler and for the eco-system it formalizes a general file lookup procedure that build systems and infrastructure tools can follow to lookup compilation objects and attribute them short root names under the form of these
However at the moment dealing with opam system compilers and/or mixed opam and system OCaml package installs is messy and done entirely in ad-hoc fashion by these tools -- see the first two points here. I think it would be beneficial for the eco-system if upstream helps in formalizing this. Doing so should have no impact on the
The ideas behind this move are the following:
The idea is that in opam switches
Note that all of this does absolutely not touch the problem of looking up objects/libraries and their dependencies and constitutes in no way an
This is mostly similar to @lpw25
I argue the proposed scheme is not less powerful than the one @lpw25 proposes. In practice you can always rename by creating a directory with appropriate symlinks that you put in front of
One issue that needs to be touched with this proposal, is that
Note except for the "where is the
The idea of installing the standard library in
The core of your proposal is to eventually be able to write
You propose to keep
In terms of "nice final state", I feel it would be nicer to interpet
One thing that has come up trying to work through the problems with
@gasche Thanks for your comments.
I agree this is not a good idea and should not be done because it doesn't bring us to a "nice final state". If we do this there's an unwanted aspect due to include paths that are prefix of each others; in an opam non-system switch with
However the problem we have is the following: in the current world, system packagers (e.g. debian) and some opam packages (IIRC mostly stuff build with
So if we set
With the problem that some packages show up under different names. This is not a problem if you are specifying name constraints or lookups, it is however if you are trying to list things (list all installed packages and subpackages) or attribute files to package names (e.g. for generating documentation).
So to sum maybe the best is to simply:
In the debian case this would entail e.g. installing ocaml packages in an
@dra27 I'd rather keep the semantics of
EDIT: First because "smart" things tend to make things more complicated to understand when they go wrong. Second because the lookup procedure should be easy to implement by other tools that are not part of upstream.
What's the reason to change the directory name?
Or are you proposing that the ocaml compiler continues to use
I would also note incidentally that Perl and Python have the concept of vendor and site install directories. I've never found this anything other than confusing however and it's also largely irrelevant when you're using a proper package manager.
@rwmjones in short you are free to do what you want, the only thing we don't want is to have the
Why ? Because we would like to be able to get to a system where OCaml packages and subpackages can be specified via relative paths (e.g.
With the current install structures either we set OCAMLPATH to
In my namespacing design, I proposed adding a
I do not get the overall rationale of this. What is wrong with ocamlfind? It seems to already support an
Nowadays, I consider the
Speaking with my Debian hat, I am not fond of gratuitously introducing another new directory in /usr/lib. However, I agree it would be cleaner to put stdlib in its own sub-directory of
Did you ever try to explain the way the OCaml eco-system is structured to a newcomer ?
At the moment we have:
From that perspective what
If we all try to cooperate here, we can gradually streamline the naming orgy we have at the moment with little end-user disturbance and move towards a system that is easy to explain both to newcomers and to ourselves with as little concepts and names as possible and whose structure is apparent by simply consulting the file system.
As I said to @rwmjones that's for you to choose, you could elect to have the libdir of the ocaml compiler install be
Again the only thing that is being asked here is:
This I will let @gasche defend more thoroughly if needed, but I agree with him that
In Fedora today (at least: on my machine), OCaml packages live in
Re. ocamlfind: personally I am in no hurry to replace ocamlfind which has served me well over the years and continues to do a superb job, but I also agree with Daniel's point that there are too many different concepts in the OCaml packaging ecosystem, and I am happy that some people continue to experiment with alternative approaches to improve our tooling. If there is a plan that makes some new experiments possible, some things simpler, I think it's worth playing along.