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

Support ~/.config/opam (per XDG base dir spec) #3766

Open
lgarron opened this issue Feb 26, 2019 · 7 comments
Open

Support ~/.config/opam (per XDG base dir spec) #3766

lgarron opened this issue Feb 26, 2019 · 7 comments
Assignees
Projects

Comments

@lgarron
Copy link

lgarron commented Feb 26, 2019

There is a de facto standard that aims to give an alternative to every program creating its own hidden dir directly under the home dir: the XDG base dir spec.

Would it be possible to do one of the following?

  • Move the config directory to $XDG_CONFIG_HOME , falling back to ~/.config/opam (then optionally falling back to ~/.opam for legacy compat)
  • Move the config directory to ~/.config/opam (optionally falling back to ~/.opam for legacy compat)
  • Allow setting the opam directory location using an env var.

Many programs allow one of these, as documented at https://wiki.archlinux.org/index.php/XDG_Base_Directory
I want my home directory as uncluttered as possible, and any of these would help with that goal – although the most standard approach would be nicest.

@lgarron lgarron changed the title Support XDG base directory specification Support ~/.config/opam (per XDG base directory specification) Feb 26, 2019
@lgarron lgarron changed the title Support ~/.config/opam (per XDG base directory specification) Support ~/.config/opam (per XDG base dir spec) Feb 26, 2019
@avsm
Copy link
Member

avsm commented Jun 19, 2020

Just to get this started, you can export OPAMROOT=$XDG_CONFIG_HOME/opam. However, it's considerably more work to tease out the bits of opam that are switch-specific (to move into XDG_RUNTIME_DIR or similar).

@GarkGarcia
Copy link

Just added an entry for opam in https://wiki.archlinux.org/title/XDG_Base_Directory.

Just to get this started, you can export OPAMROOT=$XDG_CONFIG_HOME/opam. However, it's considerably more work to tease out the bits of opam that are switch-specific (to move into XDG_RUNTIME_DIR or similar).

Could you please let me know if there is any aditional configuration required to make export OPAMROOT=$XDG_CONFIG_HOME/opam work? Does opam env pick up on OPAMROOT automatically or should users configure OPAM_SWITCH_PREFIX/CAML_LD_LIBRARY_PATH/OCAML_TOPLEVEL_PATH/PKG_CONFIG_PATH manually?

@dra27
Copy link
Member

dra27 commented Jul 14, 2021

opam will pick up everything required from OPAMROOT - those other environment variables are altered by the opam env command and shouldn't be being set by hand.

However, this puts an entire root (binaries, etc.) into a .config directory, which is not the intention of XDG (and is what #3766 (comment) refers to)

@dra27
Copy link
Member

dra27 commented Jul 14, 2021

opam should continue to check ~/.opam first - but if no root is found either there or in the XDG structure, opam init would default to setting up the root using XDG directories (maximum compatibility).

I think layout should work:

  • Switches stored under XDG_DATA_HOME. We could separate .opam-switch, but I think it's better to keep switches in one directory.
  • .opam/config, .opam/repo/repos-config and .opam/opam-init stored under XDG_CONFIG_HOME.
  • .opam/logs, .opam/download-cache and package repositories stored under XDG_STATE_HOME.

opam doesn't need to put anything under XDG_RUNTIME_DIR. I'd propose we introduce a new variable $OPAMROOTNAME with default value opam, so the config lives in $XDG_CONFIG_HOME/$OPAMROOTNAME/config which for advanced users still allows multiple roots to exist in XDG. Note that we could have all roots share the download-cache and logs directories (i.e. regardless of $OPAMROOTNAME, the download cache lives in $XDG_STATE_HOME/opam/download-cache). The repository clones would want to respect $OPAMROOTNAME, obviously. All that said, I think the set of people who have multiple opam roots is a subset of the core opam developers!

Note that the *_DATA_DIRS conventions mean that one could end up trying to use mis-matching switches or repository clones.
.opam-switch/switch-config already references the opam-root - the repository clones would also need to start referencing the root they belong to.

Most of this just involves a certain amount of mangling in OpamPath and then ensuring that what's being loaded belongs to the correct root.

@GarkGarcia
Copy link

However, this puts an entire root (binaries, etc.) into a .config directory, which is not the intention of XDG (and is what #3766 (comment) refers to)

Yes, I am concerned about that too. As a (hopefully temporary) comprise, I'll add instructions in the Arch wiki to configure OPAMROOT to $XDG_DATA_HOME/opam.

@dra27 dra27 self-assigned this Jul 16, 2021
@dra27 dra27 added this to To do in Opam 2.2.0 via automation Jul 16, 2021
@dra27 dra27 mentioned this issue Aug 30, 2021
1 task
@dra27 dra27 moved this from To do to Bump to 2.3? in Opam 2.2.0 Feb 11, 2022
@dra27 dra27 added this to To do in Opam 2.3 via automation May 17, 2022
@dra27 dra27 removed this from Bump to 2.3? in Opam 2.2.0 May 17, 2022
@jonahbeckford
Copy link
Contributor

@dra27 Is this coming in Opam 2.2? All Diskuv Windows patches have been incorporated into the Opam trunk (thanks!) except this change per the discussion in #4815 which fixes the Windows path only:

jonahbeckford@b6ba2e1

let default = {
  root_dir = OpamFilename.(
      if Sys.win32 then
        (* CSIDL_LOCAL_APPDATA = 0x1c *)
        concat_and_resolve (Dir.of_string (OpamStubs.(shGetFolderPath 0x1c SHGFP_TYPE_CURRENT))) "opam"
      else
        concat_and_resolve (Dir.of_string (OpamStd.Sys.home ())) ".opam"
    );

@dra27
Copy link
Member

dra27 commented Aug 2, 2022

XDG itself is definitely bumped from 2.2 - partly because it's not been done but also because it would involve a root version bump, which isn't otherwise needed in this release (so we'd break compatibility with tools using the old libraries for no other reason than switching to XDG).

However, the Windows default location for the root is separate from that - see #5212 which should be entirely Diskuv-ready!

jonahbeckford added a commit to diskuv/dkml-runtime-common that referenced this issue Dec 1, 2023
jonahbeckford added a commit to diskuv/dkml-runtime-apps that referenced this issue Dec 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Opam 2.3
  
To do
Development

No branches or pull requests

5 participants