This package automtically create the environment and installs the needed packages when you run the Julia program (assuming “using QuickEnv” is at the top). Julia also has a neat feature of named environments, and QuickEnv search & find such an environment that the program can use to run in, and use it, instead of creating a new environment. So, for example, you can setup a named environment that is sufficient for most of your programs, and QuickEnv would automatically default to using this environment. QuickEnv also has a mechanism for setting up such named environments.
Since the default behavior of QuickEnv is to create a local environment in the current directory, this avoids the natural behavior of over-installing packages in the global environments. For more details, see here:
I think this is useful, but I would not be shocked if somebody came up with a more elegant solution. I just didn’t find it… (My previous solution was to have a different shabang that defaulted to running the program in the current directory environment.)
Local Directory Projects (--project=.): Reproducible, but creates directory clutter and repetitive setup overhead for single-file scripts or quick calculations. Furthermore, it results in additional disk space usage and compile-time overhead due to redundant package downloads and precompilations.
I don’t believe this is true.
For the “clutter” it is just a matter of:
using Pkg
PKG.activate(@__DIR__)
For the disk space, also I don’t believe it’s true: packages are not download d multiple times and precompiled package can be reused between environments (at least I think).
I’d say my package is a bit more verbose but also more principled, in that it includes the project file into the script, so you can have greater control over the project (like compat bounds and sources).
It’s not registered.
Here’s the example script from the readme:
# /// project
# name = "example"
#
# [deps]
# Example = "7876af07-990d-54b4-ab0e-23690620f79a"
# ///
using SelfContainedScripts
SelfContainedScripts.activate()
using Example
@show Example.hello("Alice")
I don’t necessarily disagree, but let me point out that “using QuickEnv” is easier. And as pointed out by the package description, since it uses a named environment if it can find one, it does save (maybe a bit) of disk space. It definitely saves runtime in such a case, as the script/program starts immediately if such a named environment exists.
As for the comments as directives. I think this is common. If there is a better alternative, I would be happy to use it.
It does feel a bit too “magic” for my tastes to be honest. I’d rather my package management be very explicit, and once you start going with those special comments then why not just have a full UV like approach instead? So being explicit rather than defining what you want in a roundabout way by tweaking the behaviour of an algorithm with unclear semantics.
Well, possibly next to the already existing in the ShareAdd.jl two macros: @usingany (which imports from any available environment) and @usingtmp (which creates a temporary environment), add third one @usinghere which creates or updates environment in the script’s directory, or, if this directory’s name is src, in it’s parent directory.
