Skip to content
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

Closed
vicuna opened this issue Jul 25, 2012 · 9 comments
Closed

It would be nice to be able to set up OCAMLINIT root directory #5699

vicuna opened this issue Jul 25, 2012 · 9 comments

Comments

@vicuna
Copy link

vicuna commented Jul 25, 2012

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

@vicuna
Copy link
Author

vicuna commented Jul 25, 2012

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.

@vicuna
Copy link
Author

vicuna commented Jul 25, 2012

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.

@vicuna
Copy link
Author

vicuna commented Jul 26, 2012

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:

  • should OCAMLINIT point to a directory or to a file? First would allow to load different file from a collection of files in the same directory. I think maybe providing both would be useful - check if it's an existing file otherwise do the same as now.
  • should we allows several paths in OCAMLINIT, colon separated?
  • I'm not sure how secure is to provide this override - e.g. if something sets OCAMLINIT to some malicious piece of code, but that's perhaps a separate consideration as always something can create/add code Caml code to .ocamlinit
  • the documentation (e.g. man pages) would need to be updated too reflecting changes

@vicuna
Copy link
Author

vicuna commented Jul 26, 2012

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 ?

@vicuna
Copy link
Author

vicuna commented Jul 26, 2012

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.

@vicuna
Copy link
Author

vicuna commented Oct 24, 2012

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.

@github-actions
Copy link

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.

@github-actions github-actions bot added the Stale label May 15, 2020
@dbuenzli
Copy link
Contributor

@avsm may want to comment but I suspect his use case is solved by the less powerfull mecanism brought by OCAML_INCLUDE_PATH, available since 4.08.0, see #7808 and #1841. In particular this comment indicates why this was needed for the opam story.

@github-actions github-actions bot removed the Stale label Jun 22, 2020
@github-actions
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants