Here is a proof of concept for the tag-based solution:
https://gist.github.com/wojtekmach/2c59fb3c3c1c274e35d164014662975a
Of course it would be slightly different as part of ExUnit, but you get the
idea. (And you can play with _this_ in your projects right now!)
> On 27 Jun 2020, at 13:17, Wojtek Mach <woj...@wojtekmach.pl> wrote:
>
> The downside of doing work in setup/0 is if you only need temp dir for one
> test, unless you mess with tags which adds boilerplate, you’d unnecessarily
> create dirs for tests that don’t need it. But then again you could argue that
> if you need it in just one test, do it in that test :) still I think it’s
> worth removing boilerplate.
>
> Contrary to the above mentioned golang issue, I am not super concerned about
> leaking temp directories, so I wasn’t planning to do that. Though being able
> to automatically remove those is arguably the only reason for tight
> integration with exunit. As you can see the implementation is currently
> fairly generic.
>
> I focused on the ex_unit case but a more general utility is interesting too.
>
> About @tag tmp_dir:
>
> @tag tmp_dir: true
> test “foo”, %{tmp_dir: tmp_dir} do
>
> seems to strike a good balance between being explicit and easy enough to use.
> 👍
>
>> On 27 Jun 2020, at 12:47, Devon Estes <devon.c.es...@gmail.com> wrote:
>>
>>
>> What are the rules for deleting this directory after it’s done being used?
>> Would it be deleted after the test finishes, or would it remain until the
>> user deletes it?
>>
>> In general this seems ok to me, but it’s also a bit limiting as you only get
>> one directory per test. I’d personally prefer to see something where you get
>> one directory per process instead of one directory per test, or when each
>> call to temp_dir! returns a new, unique directory as this covers some other
>> common use cases (like parallel processing of files in multiple folders)
>> without having to first create the temp_dir for the test and then in that
>> temp_dir additional directories per process. I do this generally using UUIDs
>> to create temporary directories, and I haven’t (personally) had any issues
>> with debugging or anything, but I can see how this might be confusing for
>> folks.
>>
>> Wojtek Mach <woj...@wojtekmach.pl <mailto:woj...@wojtekmach.pl>> schrieb am
>> Sa. 27. Juni 2020 um 12:19:
>> It’s common to create temporary directories for tests, ideally a unique
>> directory per test to run them concurrently.
>>
>> I’d like to propose adding `ExUnit.Callbacks.tmp_dir!/0` and this is how we
>> could use it:
>>
>> defmodule MyTest do
>> use ExUnit.Case, async: true
>>
>> test "my test" do
>> assert tmp_dir!() =~ "my test"
>> assert File.dir?(tmp_dir!())
>> end
>> end
>>
>> The directory is lazily created on the first call, the second call to that
>> function within the same test simply returns the same path.
>>
>> While the path must be unique per test, I believe it should also be
>> predictable to ease debugging, I picked: tmp/<module>/<test>.
>>
>> To extract the module & test name, we have two options:
>>
>> 1. Define tmp_dir!/0 as a regular function and use stack trace
>> 2. Define tmp_dir!/0 as a macro
>>
>> Here’s a proof of concept for option 1:
>>
>> - the code:
>> https://github.com/wojtekmach/elixir/commit/4c399540802a3cae583c086d865dc90d865df6c8
>>
>> <https://github.com/wojtekmach/elixir/commit/4c399540802a3cae583c086d865dc90d865df6c8>
>> - example of usage in Elixir test suite:
>> https://github.com/wojtekmach/elixir/commit/01df2551582dd9acdaa2f6ff982d6767763070f1
>>
>> <https://github.com/wojtekmach/elixir/commit/01df2551582dd9acdaa2f6ff982d6767763070f1>
>>
>> The downside of using stack trace is it can easily get mangled, people
>> shouldn’t do this:
>>
>> test "my test" do
>> tmp_dir!()
>>
>> Task.async(fn ->
>> tmp_dir!()
>> end)
>> |> Task.await()
>> end
>>
>> And instead do that:
>>
>> test "my test" do
>> tmp_dir = tmp_dir!()
>>
>> Task.async(fn ->
>> tmp_dir
>> end)
>> |> Task.await()
>> end
>>
>> I believe documenting this might be enough.
>>
>> This proposal is inspired by https://github.com/golang/go/issues/35998
>> <https://github.com/golang/go/issues/35998>.
>>
>> Any feedback appreciated!
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "elixir-lang-core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to elixir-lang-core+unsubscr...@googlegroups.com
>> <mailto:elixir-lang-core%2bunsubscr...@googlegroups.com>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/elixir-lang-core/066A99E3-B470-44C3-9632-F52E97AB8791%40wojtekmach.pl
>>
>> <https://groups.google.com/d/msgid/elixir-lang-core/066A99E3-B470-44C3-9632-F52E97AB8791%40wojtekmach.pl>.
>> --
>>
>> _________________
>> Devon Estes
>> +49 176 2356 4717
>> www.devonestes.com <http://www.devonestes.com/>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "elixir-lang-core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to elixir-lang-core+unsubscr...@googlegroups.com
>> <mailto:elixir-lang-core+unsubscr...@googlegroups.com>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/elixir-lang-core/CAGowJcgGwFrF%2Btf%2BjmKnFSzntuVUX7pLb2Mj4jsvP6XyBXXo%2Bw%40mail.gmail.com
>>
>> <https://groups.google.com/d/msgid/elixir-lang-core/CAGowJcgGwFrF%2Btf%2BjmKnFSzntuVUX7pLb2Mj4jsvP6XyBXXo%2Bw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/82DDE90B-0A6E-4EE7-AB95-A4876B08C4B8%40wojtekmach.pl.
