Proposal: Add tempdir utilities Stdenv.tmp, Path.open_temp_dir, etc.

[vog]

Currently, Eio has no facilities for managing temporary files directories.

I propose to add a new capability Eio.Stdenv.tmp that points to the system temporary directory (e.g. /tmp), which represents the capability to create temporary files or directories. In a first step I'd propose to just wrap Filename.get_temp_dir_name:

let tmp : Eio.Fs.dir_ty Eio.Path.t =
  Path.(fs / Eio_unix.run_in_systhread Filename.get_temp_dir_name)

Of course, some solution without Eio_unix.run_in_systhread would also be nice.

In addition I'd propose to add a typical open/with pair of functions to Eio.Path for creating (and automatically removing) temporary directories:

let open_temp_dir ~(sw : Switch.t) ?(perms : int = 0o700)
    ?(prefix : string = "tmp-") ?(suffix : string = "")
    (tmp : Fs.dir_ty Path.t) : [< `Close | Fs.dir_ty ] Path.t
    =
  let temp_dir_string =
    let tmp_string = native_exn tmp in
    Eio_unix.run_in_systhread @@ fun () ->
    Filename.temp_dir ~temp_dir:tmp_string ~perms prefix suffix
  in
  let temp_dir = tmp / temp_dir_string in
  Switch.on_release sw (fun () -> rmtree ~missing_ok:true temp_dir);
  open_dir ~sw temp_dir

let with_temp_dir (type a) ?(perms : int option) ?(prefix : string option)
    ?(suffix : string option) (tmp : Fs.dir_ty Path.t)
    (f : [< `Close | Fs.dir_ty ] Path.t -> a) : a =
  Switch.run @@ fun sw ->
  let temp_dir = open_temp_dir ~sw ?perms ?prefix ?suffix tmp in
  f temp_dir

As seen above, I'd propose to differ from Filename.temp_dir in that prefix and suffix should be optional with their typically used defaults. And, again, in the future we might replace it with something that doesn't need Eio_unix.run_in_systhread.

The usage would look like this:

let () =
  Eio_main.run @@ fun env ->
  let tmp = Eio.Stdenv.tmp env in
  Eio.Path.with_temp_dir tmp begin fun temp_dir ->
    ...
  end

In addition, one might think of functions to create temporary files as well, but I believe the above would be the perfect start, as once you can safely create temporary directories, you can also put any further files into it. The latter has the advantage that you have full control over their filenames, which is especially handy when wrapping command line tools.

• Does this make sense to you?
• Would you accept a PR implementing this?
• Do you have proposals for improvement?
• Would it make sense to have a separate resource type for Stdenv.tmp? This way, we could restrict this to the creation of files and directories, without allowing a function to access any other temp files that some other corner of the application might have created. On the other hand, this might be overengineering. What do you think?

[vog]

@talex5 Any objections?

[patricoferris]

Thanks for these suggestions @vog, I have found myself reaching for something like this quite often and ended up doing something similar with Eio.Stdenv.fs and Filename.temp_....

As seen above, I'd propose to differ from Filename.temp_dir in that prefix and suffix should be optional with their typically used defaults. And, again, in the future we might replace it with something that doesn't need Eio_unix.run_in_systhread

Given we have all of the necessary functions in Eio.Path, might it not be too much hassle to go ahead and implement this directly without going through Filename? Eio itself should not have a dependency on eio.unixso you won't be able to use run_in_systhread.

I propose to add a new capability Eio.Stdenv.tmp that points to the system temporary directory (e.g. /tmp), which represents the capability to create temporary files or directories.

My initial feeling is that providing this through Stdenv probably makes sense given different backends will point at different places (e.g. /tmp or whatever TMPDIRis or get_temp_path on windows etc.)

A final note on the API design, any time I have used temporary directories, there inevitably comes a point where I want the function to not cleanup after me, I wonder if we shouldn't make this possible via an optional argument? (Users could provide their own Stdenv.tmp but that seems a lot of hassle to me).