fix for attempting to remove a lib when dev is set

[ninjamuffin99]

• run something like `haxelib git [lib] [url]
• set a devpath somewhere haxelib dev [lib] path
• try to remove the git haxelib with haxelib remove [lib] git

Error: Library haxelib version git is not installed

currently Repository.removeProjectVersion() doesn't check if we're using a dev path, it only checks the .current file. So here we check if we have a .dev file (using getDevPath() which returns null if no .dev file is found)

This PR just adds a simple check calling getDevPath to see if we are using a dev path, in which case we should be able to remove the git version of a haxelib

[ninjamuffin99]

one thing this doesn't accomodate for yet, it should change the .current file right 🤔? right now it doesn't do that... so returning to the non-dev version it would try to use git version.

[kLabz]

This PR doesn't seem to do what the description says 🤔

The codepath leading to the error you mentioned has not changed. Changing the behavior when removing the version used as "current" might not be what we want either, and implementation seems wrong anyway.

[ninjamuffin99]

hrmm I suppose what I'm trying to do is: when using a dev version for a haxelib, and then explicitly asking to haxelib remove a specific version, we should be able to remove the version, since we aren't using it (we are using the dev version`.)

haxelib remove acts as if you're still using a non-dev haxelib, so it will run to see if the "current" set version of a haxelib is the one you want to remove. I feel like this is incorrect behaviour, since it's NOT being used currently, the dev version is after running haxelib dev. However haxelib uses 2 files to track versions

• .current, whether we should look in a semantic version styled folder for our code, and which one we should use. Can also be set to git
• .dev, if this file exists, we are using a development version, within is just the full path to the haxelib somewhere on your machine. If this file doesn't exist, we are NOT using a dev directory

So Repository.removeProjectVersion()'s current implementation doesn't care if you have a .dev file or not, if the .current file is set to something you want to remove, it will refuse and error.

Repository.getDevPath() will return null if .dev doesn't exist, so that's the check I used in the if statement

[kLabz]

We really don't want that. Especially since you're also doing it when removing a version that is not the current version.

[ninjamuffin99]

ah I was incorrect with this one yes.
The intention was for the case of using a dev version and if you were to remove the current version, it doesn't change anything in the .current file.

If you're on say flixel 5.0.0 (cat flixel/.current -> 5.0.0), begin using a dev directory for flixel, do something like haxelib remove flixel 5.0.0, we want to properly update .current so if you disable the dev, it leads to whatever the most recent directory is versions.pop().

However you're right, my implementation is incorrect since we don't want to remove / set the current version unconditionally!

[ninjamuffin99]

how does something like

FsUtils.deleteRec(versionPath);
		
if (current == version)
{
	var versions = getProjectInstallationInfo(name).versions.pop();
	setCurrentVersion(name, versions);
}

shake out? Unless I'm still misunderstanding 🙇‍♂️
In this snippet, the code will run if .dev DOES exist (otherwise we would have thrown an error earlier). So if we have a .dev haxelib, and we just removed our .current set haxelib, we update the .current file to the most recent version we have installed. Again, only if we are:

• uninstalling our "current" version
• we are using a haxelib dev based haxelib
• there are other versions installed