New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
It would be nice to be able to set up OCAMLINIT root directory #5699
Comments
Comment author: @avsm The background to this request is for the OPAM package manager. It can switch installed compiler versions and maintains them in ~/.opam/, along with a per-compiler ocamlfind and libraries. OPAM also has a special "system" compiler which uses any installed version of OCaml, and only installs its own ocamlfind in this case. Compilers are switched by exporting variables to the local shell, much like ssh-agent (using "opam config -env", see https://github.com/OCamlPro/opam/issues/47 for a few examples). OPAM currently sets the PATH to point to the local ocamlfind and CAML_LD_LIBRARY_PATH for stublibs. The combination of a system OCaml and OPAM would be helped by this patch, as it would permit the package manager to override the interactive top-level in the same way. |
Comment author: @lefessan I am wondering if the .ocamlinit file pointed to by $HOME or $OCAMLINIT is the same as for ./.ocamlinit : ./.ocamlinit is supposed to load values for the current project, whereas $HOME/.ocamlinit or $OCAMLINIT is more a user configuration. So, shouldn't both files be loaded, instead of just the first one found ? @avsm: how does OPAM use OCAMLINIT exactly ? I don't really understand why you need that. |
Comment author: meyer The patch looks quite useful. I think the need is that our mechanism to load the configuration is not extensible i.e. the .ocamlinit will be always loaded if we don't even want it, and if we want to load different configuration and (possibly) load the other one, one could do it with custom .ocamlinit. The other way round it would be to specify init file via. -init option in the ocaml comandline, but currently no way to cleanly disable loading completely. Notes about the patch:
|
Comment author: @lefessan Why not read all *.ml files from $OCAMLLIB/site_ocaml/ and $HOME/.ocaml/, or $OCAMLINIT/ at "ocaml" startup ? And then, afterwards, read .ocamlinit from the local directory ? And also add OCAMLPATH for include directories ? Also, wouldn't it help to transform some toplevel directives into functions that can easily be called from these files ? |
Comment author: tgazagna The problem when you have multiple files to load is that the order is important, and loading a full directory can lead to random effects depending on the loading order (which is bad). I guess the most important thing to have a way to be able to choose which .ocamlinit to load, which is not possible at the moment. From there, the .ocamlinit file can itself load some files in a directory by reading the content of another variable and doing some clever tricks to keep a consistent loading order, but that's a different concern. |
Comment author: @avsm Obtaining a consistent loading order can be enforced via a lexical convention on the names of the files (i.e. 10-foo, 20-bar, etc.), just like rc scripts on UNIX do. For package managers like OPAM, we don't want to modify any files outside of the package manager area if at all possible, and so specifying an alternative location for ~/.ocamlinit would be very useful. |
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
@avsm may want to comment but I suspect his use case is solved by the less powerfull mecanism brought by |
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
Original bug ID: 5699
Reporter: tgazagna
Status: confirmed (set by @damiendoligez on 2013-12-05T15:07:22Z)
Resolution: open
Priority: normal
Severity: feature
Version: 4.00.0+beta2/+rc1
Category: toplevel
Tags: patch
Related to: #5723
Monitored by: meyer @glondu @hcarty @avsm
Bug description
Currently, .ocamlinit is searched only in the current path and in $HOME. It would be nice to look in $OCAMLINIT as well.
This would help packaging tools to set-up an appropriate user environment to run the toplevel.
File attachments
The text was updated successfully, but these errors were encountered: