[Caml-list] Re: ~/.opam design

[Caml-list] Re: ~/.opam design

[Florent Monnier]

2013/05/29, Mr. Herr wrote:
[...]
> There are certainly advantages in the ~/.opam design decision, but I have
> yet to find out how to roll out my ~/.opam libraries for production.

I do like this design. It's very logic.
Install in the user's home is just the default behaviour.
Moreover if you want to install in the system you should login as
root, then just change the defaults for the root user to install in
the system.

For fun I've played with wrapping an opam package inside a rpm package.
I just have to tar.gz the package directory and in the .spec file, sed
the archive field for a file:// path (because not allowed to get
something from outside) seded with the archives in the SOURCES
directory of the rpm package. I init Opam and repo remove the internet
one (again nothing from outside), then install in the path that
rpmbuild wants.
There is still one detail that won't be able to be done by a script
it's when there's a C lib dependency, because Opam don't provide yet
any feature for this. But this will probably come for 2.0. So it's
potentially possible to create .rpm's for all Opam packages with
almost no or very few human work. This kind of rpm's won't fit the
Mageia packaging policy though, but we could change it to allow this,
or put an unofficial rpm repo somewhere else.

--

Re: [Caml-list] Re: ~/.opam design

[Sébastien Dailly]

Le 2013-05-29 23:29, Florent Monnier a écrit :
> 2013/05/29, Mr. Herr wrote:
> [...]
>> There are certainly advantages in the ~/.opam design decision, but I 
>> have
>> yet to find out how to roll out my ~/.opam libraries for production.
>
> I do like this design. It's very logic.
> Install in the user's home is just the default behaviour.
> Moreover if you want to install in the system you should login as
> root, then just change the defaults for the root user to install in
> the system.
>

Maybe is the subject now closed, and I'm answering too late, but I'll 
greatly appreciate if opam could follow the XDG Directory design[1] :

$XDG_CONFIG_HOME/opam (default ~/.config/opam) for the configuration
$XDG_DATA_HOME/opam (default ~/.local/opam) for the package and all 
datas

This allow to stop the polution in the users ~ , and give the user a 
way to define it's own path.

[1] 
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

-- 
Sébastien Dailly

Re: [Caml-list] Re: ~/.opam design

[Thomas Gazagnaire]

> Maybe is the subject now closed, and I'm answering too late, but I'll greatly appreciate if opam could follow the XDG Directory design[1] :
> 
> $XDG_CONFIG_HOME/opam (default ~/.config/opam) for the configuration
> $XDG_DATA_HOME/opam (default ~/.local/opam) for the package and all datas
> 
> This allow to stop the polution in the users ~ , and give the user a way to define it's own path.
> 
> [1] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

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

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). 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. Luckily, all the paths used by OPAM are defined in [4] so they can be changed without too much hassle.

Best,
Thomas

[1]  https://github.com/OCamlPro/opam/issues/401
[2] https://github.com/OCamlPro/opam/issues/398
[3] https://github.com/OCamlPro/opam-repository/issues/746
[4] https://github.com/OCamlPro/opam/blob/master/src/core/opamPath.ml

Re: [Caml-list] Re: ~/.opam design

[Sébastien Dailly]

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