allow modification of version via hooks

[djerius]

The new internal version-munge command is used to modify the version when
read from a version file or when specified on the command line via the
shell, local, or global commands. The version stored in a version
file is not modified.

This allows the user to modify the version dependent upon the existing
environment. For example, if the PLENV_ROOT directory is shared
across multiple platforms with different OS's, hardware, or ABI's, one
could modify the version at run-time to include a platform specific
suffix, allowing a single version stored in a version file to
accomodate multiple platforms.

For example, if the hostname is used to distinguish the platform, e.g.
on each host Perl was installed with

% plenv install --as 5.22-$(hostname) 5.22

Then with the following hook:

% cat ~/.plenv/plenv.d/version-munge/hostname.bash
#!/bin/bash

if [[ "$version" != --* ]]; then

suffix=$(hostname)

plenv-prefix "$version-$suffix" 1> /dev/null \
    && version="$version-$suffix"

fi

Setting

% plenv global 5.22

will set ~/.plenv/version to 5.22 and the hook will ensure that
each host will see its own version.

[syohex]

Is it enough to use plenv global 5.22-${hostname} on each platform ?

[djerius]

PLENV_ROOT is shared by all of the hosts, so PLENV_ROOT/version can't be host specific.

[dolmen]

An alternative is to not share the same PLENV_ROOT for all hosts.

Here is how to do it:

• create a different plenv dir for each host:
  git clone https://github.com/tokuhirom/plenv.git ~/.plenv-$(hostname)
• choose that dir when you load plenv in .profile/.bash_profile/.zshrc:

export PATH="$HOME/.plenv-$(hostname)/bin:$PATH"
eval "$(plenv init -)"

[djerius]

That would indeed work. I'd prefer of course to have a single plenv dir, as I am consummately lazy.

[dolmen]

I'd prefer of course to have a single plenv dir, as I am consummately lazy.

I just hope that the lazyness of the maintainers will win. ;-) Any added line of code adds maintenance burden, but also in this case, runtime cost for all users.

[djerius]

I just hope that the lazyness of the maintainers will win. ;-) Any added line of code adds maintenance burden, but also in this case, runtime cost for all users.

I have faith in their ability to apply the required amount of lazyness. This issue seems to have attracted the appropriate amount of attention from them.