fix: assign default values to all internal variables

[hyperupcall]

Summary

As mentioned here, this fixes the behavior of defaulting ASDF_DEFAULT_TOOL_VERSIONS_FILENAME to the correct version. This is also done to $ASDF_DATA_DIR.

[jthegedus]

LGTM

[jthegedus]

One assumes that the fact all our tests passed without changes that this is not a breaking change 🤔 Though it does change the behaviour of ENV VARS which are part of the "public" API so should be considered breaking 🙃

Do you consider this to be a breaking change @hyperupcall ? If this is breaking we would need to use fix!: instead of fix: for the PR title.

[hyperupcall]

Unless I'm missing something, I don't think it's a breaking change. The environment variables are a part of the "public" API as you mention, but as far as I can tell, the behavior of the env vars isn't changing, the thing that changes is where it is set (if at all).

If asdf launches a subprocess like executing a plugin, the value of the environment variable are either the same or no longer empty, so if people were depending on a non-empty value, those values don't change. And the fix is that previous unset environment variables are now set, so that doesn't break anything. I suppose theoretically someone plugin somewhere could be relying on the fact that one or more of these variables were incorrectly unset or set, but empty - I don't personally care about that because if those were breaking changes, then too many changes would be breaking change due to Hyrum's Law and semantic versioning would be meaningless to me - intent/explicitness plays a part in my opinion.

[jthegedus]

Thanks for the input, fix: it is then!

[Stratus3D]

nitpick: The default tool versions file name is .tool-versions. If the user has customized it by setting ASDF_DEFAULT_TOOL_VERSIONS_FILENAME then this function won't return the default filename. I think asdf_tool_versions_filename would be a better function name. Sorry for the late comment, but I figured I'd bring this up just for future reference.