caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Sébastien Dailly" <sebastien-ocaml@chimrod.com>
To: Thomas Gazagnaire <thomas@ocamlpro.com>
Cc: <caml-list@inria.fr>
Subject: Re: [Caml-list] Re: ~/.opam design
Date: Thu, 30 May 2013 10:14:47 +0200	[thread overview]
Message-ID: <a3fb8eabc251838bbd71927fe4b26ffa@chimrod.com> (raw)
In-Reply-To: <85FC58B0-BA1E-49C0-9380-802315C81592@ocamlpro.com>

Le 2013-05-30 09:38, Thomas Gazagnaire a écrit :

>
> The subject is not closed at all, and we might move in this direction
> in future releases of OPAM. See for instance [1]

Thanks for pointing the issue. I answerd on the mailing list without 
consulting the project site.

>
> The current design has a lot of advantages (the main one being that
> you can remove your ~/.opam if you want restart from scratch) and it
> can be tweaked to have a global installation (see [2,3], even if the
> tweak is not very well documented).

Each application has a good reason for beiing installed directly in the 
~ directory. But in a deskop usage (server is different), this finaly 
create a big polution in the user directory. The xdg try to define a 
general usage for preventing this.

> But yes, for some configurations
> (such as shared NFS homedirs), the current situation is not perfect
> and it would be nice to be able to separate the data from the
> configuration bits.

This is a more general problem : exporting the configuration from one 
site to another one, or versionning the opam conf in a production server 
is greatly facilitated if the configuration is located in a dedicated 
path.

> Luckily, all the paths used by OPAM are defined in
> [4] so they can be changed without too much hassle.

The main advantage I can see with the xdg path is that the 
configuration path is declared before installing anything, and can be 
configured once for a whole system. This allow to configure differents 
workspace just by sourcing a bash file ; as I can do with findlib and 
${OCAMLFIND_CONF}

I think you can get as many pros as cons, but today, the xdg path is a 
standard in a desktop…

Regards,

-- 
Sébastien

      reply	other threads:[~2013-05-30  8:14 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-29 21:29 Florent Monnier
2013-05-30  7:18 ` Sébastien Dailly
2013-05-30  7:38   ` Thomas Gazagnaire
2013-05-30  8:14     ` Sébastien Dailly [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a3fb8eabc251838bbd71927fe4b26ffa@chimrod.com \
    --to=sebastien-ocaml@chimrod.com \
    --cc=caml-list@inria.fr \
    --cc=thomas@ocamlpro.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).