Make hvm dot file independent of OS/environment

[salim-b]

Currently, hvm use writes the full path instead of just the version tag to the .hvm file. This makes it unsuitable to be used for projects shared between multiple people on different OS platforms since user-cache filesystem paths vary between them. .hvm in its current form is not suitable to be version-controlled (we'd have to .gitignore the file).

What do you think about changing hvm to only write the Hugo version tag to .hvm?

This would ideally be accompanied by changing hvm install to install the Hugo version recorded in .hvm if that file already exists and the respective Hugo version is not yet in hvm's cache.

With such a redesign, hvm could be used in any Hugo project repo to hardcode/synchronize the recommended/tested Hugo version.

A slightly different, more "Hugo-integrated" approach to basically reach the same goal would entail changing hvm to honor Hugo's hugoVersion module config key. But this could also be added in addition to the above.

The end goal would be to make hvm a suitable (but better) alternative to hugo-installer.

[jmooring]

only write the Hugo version tag

Not saying no, just thinking it through...

The original implementation, that I had been using for several years, wrote only the tag to the dot file. I changed it to the absolute path to:

1. Simplify the alias described in the installation instructions, keeping in mind that the path to the user cache directory varies by OS and/or environment variables.
2. Make the path to the hvm cache directory configurable in the future, potentially desirable on a multi-user system (e.g., /var/cache/hvm).
3. Keep the alias functional even if the hvm exec is removed from the system.

By storing the exec path in the dot file, the alias only needs to verify dot file existence, and read and verify its content.

If we only write the tag, the alias would need to run hvm config and parse its output¹ to determine the path to the cache directory. I suppose that doesn't add much overhead, but then hvm itself becomes a dependency (item 3).

If we don't care about item 3 above, I think I'm OK with making this change. It is also a bit more secure; we would not be relying on the alias to verify that the path is safe. Today it only verifies that the exec path ends in the exec name.

And if we're going to make a change, do it soon, noting that it's a breaking change. I have no interest or motivation to make this backwards compatible.

changing hvm install to install the Hugo version recorded in .hvm

I would only make this change by adding a flag to the hvm install command (e.g., hvm install --someThing), and given the use case as described, I consider this a low priority.

honor Hugo's hugoVersion module config key

A hard "no" on this one. Hugo itself could break this if the output from hugo config modules changes in the future, and I do not consider Hugo's CLI output to be part of its API promise.

Footnotes

1. Or we add a --printExecPath flag to the status command so that we don't have to parse. ↩

[salim-b]

but then hvm itself becomes a dependency (item 3)

True. A way to avoid this would be to incorporate resolving the user-cache dir into the shell alias. I don't know if this would be worth the hassle. If hvm would be extended to generate the shell alias code like it does for shell completion (hvm completion)¹, it could be maintainable, I guess.

Or we add a --printExecPath flag to the status command so that we don't have to parse.

This would be the way to go, I think.

And if we're going to make a change, do it soon, noting that it's a breaking change. I have no interest or motivation to make this backwards compatible.

Totally fine with me! I don't care about backward compatibility at this point.

I would only make this change by adding a flag to the hvm install command (e.g., hvm install --someThing)

That would be fine.

A hard "no" on this one. Hugo itself could break this if the output from hugo config modules changes in the future, and I do not consider Hugo's CLI output to be part of its API promise.

Ok. You can certainly assess that better than I can.

Footnotes

1. If I'm not mistaken, hvm relies on cobra for this, so doesn't have to struggle with it itself. ↩

[jmooring]

resolving the user-cache dir into the shell alias

No. This gets ugly, and prevents making the path to the hvm cache directory configurable.

extended to generate the shell alias code

This is already on my radar as a possible nice-to-have, but the only reason I'd do this is to:

1. Simplify this step of the installation, but I'm not convinced that it would actually improve anything.
2. Uncouple this step of the installation from the README.

Please create a separate issue for this.

That [hvm install --someThing] would be fine.

Please create a separate issue for this, but again, this is low priority.

This [--printExecPath] would be the way to go

Agreed. The sole focus of this issue is to uncouple the dot file from OS/environment.

I think this is valuable enough to make hvm a dependency of the alias.

[salim-b]

This is already on my radar as a possible nice-to-have, but the only reason I'd do this is to:

1. Simplify this step of the installation, but I'm not convinced that it would actually improve anything.

2. Uncouple this step of the installation from the README.

I think both are valid reasons and would make it worth to implement it. See #22.