option to keep a temporary directory after panic, for debugging purposes about tempdir

[ExpHP]

I took a similar approach to making my life easier shortly after making the issue.

Personally I think the cases where you'd expect a temporary directory not to be cleared are application specific enough that they're best handled by your application

Further making your point, the conditions I chose to leak it on were completely different from yours. I very much want this in release builds!

/// Leaks the inner TempDir if we are unwinding.
impl Drop for TempDir {
    fn drop(&mut self) {
        if ::std::thread::panicking() {
            ::std::mem::forget(self.0.take())
        }
    }
}

But I do think that panicking is special in this regard. There are many ways you could modify the behavior conditionally on debug_assertions without creating a wrapper type (e.g. a fn() -> Box<AsRef<Path>> that conditionally returns a TempDir or a PathBuf), but there's absolutely no other way to modify the behavior conditionally on unwinding.

[ExpHP]

Okay. I am closing this because there is a clear case for not building this functionality into the crate, and because I do not feel that the documentation needs to show a solution like this. I feel that somebody who is motivated enough can easily figure it out, and that the presence of the example could create unnecessary confusion.

[KodrAus]

Personally I think the cases where you'd expect a temporary directory not to be cleared are application specific enough that they're best handled by your application, building an abstraction around TempDir that persists it in debug builds on drop or something like that. Then you could have something roughly like:

struct Directory {
    inner: Option<TempDir>
}

impl Drop for Directory {
    fn drop(&mut self) {
        if let Some(dir) = mem::replace(&mut self.inner, None) {
            #[cfg(debug_assertions)]
            dir.into_path();
        }
    }
}

[KodrAus]

Yeh, I see what you mean there. The main thing making me unsure about whether we should support this as a first-class thing in tempdir are other erroneous situations besides panicking where a user might want similar behaviour or not, or do something besides not deleting the directory.

I definitely think we should at least add an example demonstrating how you can avoid dropping the directory when somebody panics like you've shown.

[otavio]

Isn't it shown at https://docs.rs/tempdir/0.3.5/tempdir/struct.TempDir.html#method.into_path ?

[ExpHP]

@otavio: But that does not delete the directory on success, almost entirely defeating the point of making a temp dir (the only remaining advantage being that you don't have to name it).

The snippet I linked earlier is an example of the desired behavior, but it is a bit beefy because it makes an effort to do everything that TempDir can. To slim it down a bit:

//! Shim around the `tempdir` crate which doesn't delete the
//! directories on unwind, in order to facilitate debugging.
extern crate tempdir;
pub use tempdir::TempDir as ActualTempDir;

use ::std::io::Result;
use ::std::path::{Path, PathBuf};

/// Wrapper around `tempdir::TempDir` that does not destroy the directory on unwind.
#[derive(Debug)]
pub struct TempDir(Option<ActualTempDir>);

// Forward inherent methods to the tempdir crate.
impl TempDir {
    pub fn new(prefix: &str) -> Result<TempDir>
    { ActualTempDir::new(prefix).map(Some).map(TempDir) }

    pub fn path(&self) -> &Path
    { self.0.as_ref().unwrap().path() }
}

/// Leaks the inner TempDir if we are unwinding.
impl Drop for TempDir {
    fn drop(&mut self) {
        if ::std::thread::panicking() {
            ::std::mem::forget(self.0.take())
        }
    }
}

[otavio]

I understand but I am unsure it is something we would like to have in production. Possibly, it might be a flag we could configure to enable/disable this behavior.

[ExpHP]

I understand but I am unsure it is something we would like to have in production.

What is the "it" you are referring to? The behavior of leaking temp directories, or the presence of a wrapper type around TempDir?

If it is the former, that is a problem that can be easily solved by anybody who wants to use this solution in their application. They could easily put the body of the drop impl in a conditionally compiled block.

(in fact, this seems a perfect example of the kind of issue @KodrAus is talking about, which shows why this functionality shouldn't be built into the tempdir crate itself. Some applications might want to #[cfg(test)] while others may want to e.g. add a feature for the behavior.)

[otavio]

@ExpHP yes, leaking temp directories.

That's exactly what I had in mind, someone desiring it would have it in a feature or cfg flag.