Does this plugin improve anything if I don't run "use asdf"?

[Mellbourn]

I'm sorry but I find the documentation a bit vague: There is a long section of motivations, that ends in claiming that this plugin can fix several problems. But does the latter assume that you have use asdf in your .envrc?

If I don't add use asdf to .envrc, do I still get any advantages from this plugin? (I'm not really interested in using different versions of direnv)

Adding things to .envrc is not always trivial, since it may belong to a repo that is shared with people not using asdf.

[michi-zuri]

you could put use asdf in ~/.config/direnv/direnvrc, as it is sourced by any .envrc, but then I'm not sure how to opt out if you don't want to use asdf for a certain project.

[Mellbourn]

Thanks, @michi-zuri, that was a helpful suggestion.

I'm still curious about my original question, though. Does asdf-direnv do anything useful without use asdf?

[smorimoto]

In that case, it just manages the direnv versions.

[airtonix]

Wouldn't it also just help us automatically set environment variables?

I mean without reading anything i would expect that something with the words:

• dir means it's directory sensitive,
• env means it sets environment variables.

or should we use something else for that basic use case?

Challenge here is that achieving adoption of asdf in a large team is simple because the documentation i have to write can be:

1. have asdf installed (which is a trivial two liner)
2. run this shell script that installs the plugins we need
3. run asdf install

but as soon as I include direnv into the mix, it suddenly gets more complicated.

[airtonix]

@Mellbourn I think the answer is that "no you do not need to use the use asdf aspect described.

bare minimum is this :

1. have asdf installed
2. have asdf-direnv installed
3. have your shells version of eval $(direnv hook bash) in your profile
4. have a .env or .envrc file in your projects directory.

Now at this level, it's debatable how useful asdf-direnv is since plain direnv will do what we're expecting, so project provisioning tools or documentation would just say :

git clone https://github.com/asdf-vm/asdf.git ~/.asdf --branch SOMEVERSION

source $HOME/.asdf/asdf.sh

asdf plugin add nodejs
asdf plugin-add pnpm
asdf plugin-add direnv

asdf install

[jfly]

I think the really confusing thing about the asdf-direnv plugin is that it's goal is to do something very different than what most asdf plugins do.

What this plugin is not for

Most asdf plugins exist to help you juggle between different versions of some development tool (python, nodejs, etc). As @smorimoto mentioned, you technically can use asdf-direnv to manage multiple versions of direnv, but I can't see why you'd want to do that: direnv is tied to your shell instance in a way where it wouldn't make any sense to use a different version of direnv in different directories. I guess you could have different shell configurations that use different versions of direnv? But I cannot imagine why you'd want to do that.

What this plugin is for

asdf-direnv lets you leverage the thing asdf is great at: installing multiple versions of the same tool without the downsides of shims. The really useful code we've written here is the use_asdf direnv helper method, and everything else is just details to help you get it installed on your system (asdf just happens to be a useful, cross platform way of distributing code). In fact, some of our users choose not to use the direnv we provide in favor of a system install of direnv, instead they just leverage our use_asdf helper (see #103 for details on that).

I've summarized a list of pros/cons below.

Pros/cons

Plain asdf

• Pro: Simpler to set up, and therefore an easier sell to a large development team
• Con: May not be able to do everything you need to get truly isolated development environments (Python virtualenvs are a good example), or you may just find shims really frustrating.

asdf-direnv

• Pro: No shims. Our README is largely dedicated to why shims suck, I won't repeat any of that here. That said, this is the kind of thing where people either "get it" or don't: if you've never been burned by shim-related weirdness, you probably won't care about this, and asdf-direnv probably isn't going to seem worth it to you.
• Pro: direnv is a useful tool in its own right! I won't get into that here, suffice to say, it's a popular tool for good reason.
• Pro: For a programming language like python, plain asdf isn't terribly useful: you're still going to end up working with a "system python", and tools like pip are going to install dependencies in a shared place where you don't want them. Instead, what you really want is asdf to control the version of Python you use, plus a little bit of direnv to automatically create or activate that virtualenv for you when you cd into the repo.

[airtonix]

• what you really want is asdf to control the version of Python you use, plus a little bit of direnv to automatically create or activate that virtualenv for you when you cd into the repo.

This might be the part that helps people understand. Perhaps with a step by step tutorial walk through illustrating the value.

[glasser]

If I understand properly, there's another thing this plugin is useful for: if you're an existing direnv user and you want to work on a project where the instructions say "hey, we manage our dependencies with asdf, install it and use it here", and you'd like to use asdf only for that project and not globally in your system (because as I said, you're a direnv user, you like keeping your configuration local)... then you can:

• install asdf
• add nothing to your bash_profile (other than what you've already added to set up direnv)
• run asdf plugin-add direnv
• plop use asdf in .envrc in the projects where you want to use asdf

Is that correct?

[jfly]

This might be the part that helps people understand. Perhaps with a step by step tutorial walk through illustrating the value.

@airtonix, this probably isn't the right place for this answer your question, but just so the answer is somewhere: if you want turnkey, isolated per directory python environments, you should should create a .envrc and a .tool-versions file in each project directory:

$ cat .tool-versions
python 3.10.2

$ cat .envrc
use asdf   # This leverages asdf-direnv
layout python  # This is built into direnv itself

$ direnv reload
direnv: loading ~/tmp/2023-02-02-pyhack-2/.envrc
direnv: using asdf
direnv: Creating env file /home/jeremy/.cache/asdf-direnv/env/1033437591-666739820-4160167590-3822053432
direnv: loading ~/.cache/asdf-direnv/env/1033437591-666739820-4160167590-3822053432
direnv: using asdf python 3.10.2
direnv: export +VIRTUAL_ENV ~PATH

Note how we're in a venv created with an asdf-managed version of python:

$ echo $VIRTUAL_ENV
/home/jeremy/tmp/2023-02-02-pyhack-2/.direnv/python-3.10.2

$ ls -alh $(which python)
lrwxrwxrwx 1 jeremy users 52 Feb  2 22:07 /home/jeremy/tmp/2023-02-02-pyhack-2/.direnv/python-3.10.2/bin/python -> /home/jeremy/.asdf/installs/python/3.10.2/bin/python

---

Is that correct?

@glasser unfortunately not quite. For that use asdf directive to work, you need a ~/.config/direnv/lib/use_asdf.sh file that defines it. For example on my machine:

cat ~/.config/direnv/lib/use_asdf.sh
### Do not edit. This was autogenerated by 'asdf direnv setup' ###
use_asdf() {
  source_env "$(asdf direnv envrc "$@")"
}

I don't think we have clear instructions for pre-existing direnv users. Perhaps we should add a new parameter to asdf direnv setup to support this (that may be what's happening over in #165, I'm not sure exactly)