Provide symlink to .gvm for compatiblity with gvm about posh-gvm

[flofreud]

Out of interest: which tools are actively looking for the .gvm folder? eg for Eclipse and Intellij I normally select gvm-installations by hand.

The symlink is not complicated to achive, but I have to consider the following:

• the .gvm and .posh_gvm folder have a similar structure for the candidates, but the meta-data file are different and the symlinks of Cygwin and Windows arn't compatible, too. Therefore I used a different folder name so that there are no conflicts between a dual installation of posh-gvm and "cygwin-gvm".
• Setting a symlink automatically could be confusing for the user. Normally this should be explained why there are now "two folders" in the home-dir. Also what should be done if there is already a .gvm folder? Should posh-gvm use .gvm as default if there is no used yet and we ignore the corner-case of later dual-installation?

Probably I could change the installation script and add an additional Install.ps1 for PsGet installations for asking the user if he wants the symlink or we put the necessary command in the readme?!

I'm not sure what the best solution could be, but if you can give me examples for the such tools, it could be easier to decide this.

Without further dependencies and check the following code would create the symlink:

Invoke-Expression -Command "cmd.exe /c mklink /J '$env:USERPROFILE\.gvm' '$env:USERPROFILE\.posh_gvm'"

Possible solutions:

1. Setup symlink without asking if not .gvm folder.
2. Setup symlink without asking and removing of the .gvm folder.
3. Changing posh-gvm to be 'compatible' to the bash-gvm folder in a way which does not clash (at least against a current version). This would need a different name for current-candidate-version symlink.
4. Extending README with explanation about usecase and the command above.

[jbaruch]

OK, plural was an overstatement :) I am trying to use https://github.com/noamt/sgvm with posh-gvm.

[flofreud]

SGVM doesn't use the the symlinks inside of the .gvm dir and therefore could be used with the .posh_gvm dir.

But for meta-data it use the same structure like bash-gvm. Probably I was not one of my better choices to change it, but I wanted to put all meta-data into one location. Therefore it would change the structure of the posh_gvm dir, if used to install new versions. Currently there would be done no harm, so it would be possible.

SGVM, which is normally used in CI environment, itself is able to install version by so posh-gvm isn't really needed, right? Could it be that your single aim is to reuse already available packages in a development environment for a CI system? If it is that, wouldn't the documentation of this possibility solve this special usecase only relevant for a really small group of users?

I don't really like the named side-effects and solution 3 would be too time consuming considering the currently little gain.

If you are currently developing a tool for general usage on a dev machine, it would be a probable a different answer but currently I would lean towards solution 4.

[jbaruch]

You are probably right. If the meta-data is different, it will be easier to document this corner-case in SGVM then trying to work around it in posh-gvm, so please disregard.

Keep up the good work!

[flofreud]

If this is getting more important I could try to find the time to get the meta-data inter-operable. Honestly didn't see this usecase coming and regret the decision. What's done is done. I currently have no time slot for changing the meta-data handling correctly.

[jbaruch]

That's fine.
A well documented single call to mklink is not a big deal.