Don't encourage distribution of repetitive removal files in opam metadata

[dsheets]

package.install:

etc: [
  "setup.ml"
  "setup.data"
  "setup.log"
  "_oasis_remove_.ml"
]

and

_oasis_remove_.ml:

open Printf

let () =
  let dir = Sys.argv.(1) in
  (try Sys.chdir dir
   with _ -> eprintf "Cannot change directory to %s\n%!" dir);
  exit (Sys.command "ocaml setup.ml -uninstall")

get added to every version of every package that uses this tool and are distributed to every user of opam even if they don't use those packages. They are always the same. They increase bandwidth and storage costs with very little benefit. They belong in the build system of the package. They make opam package analysis harder because the package is no longer self-contained.

Perhaps the solution is to upstream oasis changes so setup.ml can change its own directory?

[Chris00]

On Thu, 4 Feb 2016 12:01:16 -0800, David Sheets wrote:

Perhaps the solution is to upstream oasis changes so setup.ml can change its
own directory?

This was upstreamed a while ago but a new release of oasis needs to be made — not really my decision to make.

Another possibility is that opam offers a portable way to change directories (say a variable "cd" that gets expanded according to the platform). It is not the case at the moment.

Also, this file only gets added when an executable is built — packages providing only libraries do not need it.

[fxfactorial]

@Chris00 FWIW I like oasis2opam a lot, it makes my life easier, thank you.

Isn't oasis "owned" by ocaml.org? Who then can do a release of oasis without stepping on anyone's toes.

[dsheets]

@Chris00, what is the current workflow for the generation and distribution of these files? Is there some way to encourage their inclusion in the package itself, rather than the opam repository? Ideally, the .install file would be part of the package itself and generated based on _oasis metadata indicating what, exactly, is installed. Then, setup.ml and friends would not even be necessary for removal. Wdyt?

[Chris00]

The better would be that oasis generates an .install file — it cannot be statically included in the tarball because it may change according to the platform (on Windows executables require the .exe or .com extension, only the bytecode compiler may be present,...).

Alternatively, one may want to install executables with ocamlfind (must check that they then get automatically removed using ocamlfind remove).

[dsheets]

It can be statically included in the tarball because it is being statically included in the opam repository.

Yes, it would be ideal if oasis generated a complete .install that had all the files being installed. For now, I am only interested in having the files shown at the top of this issue included in packages.

[Chris00]

The only file that can be statically included in the package is _oasis_remove_.ml (the other ones are not included in opam anyway and record the configuration of the host on which the package is compiled). I am thinking to instead use different rules (in opam) conditioned by an os property to circumvent this script. Would that be an acceptable (short–medium term) solution to you?

[dsheets]

I believe package.install can also be included:

etc: [
  "setup.ml"
  "setup.data"
  "setup.log"
  "_oasis_remove_.ml"
]

Clearly this is currently included statically in the opam metadata files directory so I see no reason why it shouldn't be in the package. Why can't it be in the package?

So long as oasis2opam packages don't bundle files in files/ that should be in the official package archive, I don't mind how the install commands look.

I believe you can use something like ["sh" "-c" "cd %{etc}% && ocaml setup --uninstall"] in the opam file to avoid the _oasis_remove_.ml script.

[Chris00]

This is fixed by commits 8c1ab0e and ad7c1f9. Note that it does not force the user to put the files in the tarball, it only issue a warning if they are not (--local on the other hand puts the file in the root of the project).

[fxfactorial]

@Chris00 Great thank you, I always use oasis2opam --local