I am aware of activate --temp, but adding any package always seems to involve a lot of precompilation, so not ideal for quickly testing things.
Are there some additional convenience options for --temp that I am overlooking or should I just create some “scratch” project for trying things out in? This approach feels messier since it will just keep around things from previous tests as part of the project and manifest .toml files.
I guess the setup I am looking for would be one that wipes those config files at the end of the session but still keeps around the results of precompilation, but maybe someone has better ideas.
Personally, I keep a global @sandbox environment in which I regularly purge the contents and install new things. It’s essentially like a --temp but I can reuse it several times if I’m working on the same little bit of code. Other than that, I have some global environments dedicated to specific themes (@autodiff, @gpu) which contain relevant packages for these fields, that are amortized rather fast. It’s much better than always going Test.activate() in my experience.
I also know that there are options to make compilation less burdensome:
They’re not. Precompile cache is evicted when you have more than JULIA_MAX_NUM_PRECOMPILE_FILES cached file for the given package in the given version of Julia, regardless of which environment the precompile cache was created in, temporary or not.
You’re right, I probably mis-inferred Julia’s behavior due to the fact I was only using it very sparingly until now. After testing things out more systematically, it does seem like the default behavior is just what I had hoped for!