direnv is a very well known environment variable manager for your shell. It knows how to hook into bash, zsh and fish shell to load or unload environment variables depending on your current directory. This allows you to have project-specific environment variables and not clutter the " /.profile" file.
Due to the way it works it needs free access to the filesystem and environment requires clasic confinement.
You can refer to direnv.net for more information on direnv while packaging can be found at github.com/ipolyzos/direnv-snap.
I don’t think this should need classic confinement. What about the way it works requires it have ‘free access to the filesystem’?
direnv loads or unloads environment variables depending on your current directory. As per the direnv man page, it checks for the existence of a “.envrc” file in the current and parent directories. If the file exists, it is loaded into a bash sub-shell and all exported variables are then captured by direnv and then made available to your current shell.
“For direnv to work properly it needs to be hooked into the shell. Each shell has it’s own extension mechanism.”
This snap could use personal-files to enumerate the different files needed by the extension mechanisms. Can you list all of the files direnv needs access to for extending the shells?
Direnv loads ‘.env’ files and create env variables. You can have ‘.env’ files literally anywhere in the system as you wich and usually you can find them in project folders. This depends on the user.
so, you could use the
removable-media plugs to load
.env files from most reasonable places, and a
personal-files to have
$HOME/.env. What else would you need?
edit to add: the
.env files can’t be the extension mechanism, so I’m missing something.
I find the restrictions to be very strict for such a generic tool.
i am not sure that “the .env files can’t be the extension mechanism” ?
the idea is that in any file you enter if you habe a .ent it will be loaded and change your environment variable till you exit the folder …
Dot files are only blocked in the user’s toplevel home directory, not subdirectories. If you connect home and personal-files, you would be able to write $HOME/.env, $HOME/subdir.env, etc.
thanks alot @jdstrand, this is nice.
what about .env files that reside in other locations in the system thought? e.g /opr,/var etc
(it is this requirement the reason use classic)
Specific locations in /etc are supported by the system-files interface, but arbitrary locations are not. Please keep in mind that these other locations are readonly when in strict mode since the runtime environment of the snap is different in strict mode than classic. I suspect that direnv is most usable for non-root users and therefore strict home with home, removable-media, etc is good enough. Are there normal use cases where an admin wants to sprinkle .env files throughout the entire filesystem?
I agree with your comments. There is use cases though that .envrc is used as an initialisation script, this may need access to binaries such as ‘curl’ for example or other applications installed in your machine.
Can you describe typically use cases for when would run curl or other binaries? I’m sorry I’m not more familiar with direnv. I thought I understood it to be a way to set env vars depending on the dir you were in, but don’t understand how that ties in to using arbitrary commands. I think this is the last point for understanding if strict mode will work or not.
direnv as described in the projects homepage is an environment switcher for the shell. “It knows how to hook into bash, zsh, tcsh, fish shell and elvish to load or unload environment variables depending on the current directory”.
The use of direnv through expands more than just env creation and alteration. An example could be a workspace working with Python, Ruby or any specific language that would need to call tools such compiler/interpreter from your .envrc file. Another might be a kubernetes or etcd workspace environment that you would like to download and configure_kubectl_ or etcdctl. Finally working with AWS or GCP cli tools to expand your env and integrate with your cloud. The use cases of using curl and binaries I sendless i believe.
Based on the latest information the requirements are understood.
@pedronis, can you weigh in? This application has similar requirements as to an IDE or similar in that it sets up shell environments that can run arbitrary commands, in this case based on the directory. The user must configure the directory to configure and use direnv and will put in the commands to run. This is a bit different from other requests, like IDEs, but sufficiently similar I think it probably warrants classic.
I think technically it would be ok to give classic to this, but it doesn’t seem the snap is being published by upstream? which I think is problematic. Have we so far granted classic so far in cases where publisher != upstream?
Thanks everyone for your input. The requirements are understood and @pedronis ack’d this for classic once the publisher is vetted.
@Wimpress, @popey, @Igor and @evan - can one of you perform publisher vetting?
Ping - @Wimpress, @popey, @Igor and @evan - can one of you perform publisher vetting?
Ping - @Wimpress, @popey, @Igor and @evan - can one of you please perform publisher vetting?