Using dev mode for git/hg checkouts

[nadako]

Right now, when one does haxelib git libname ..., it checks out into git directory inside library folder and then sets it as a .dev path. I think that doesn't make much sense, and we should keep dev mode separated from git/hg checkouts. What I propose is to remove setting .dev and store "git" version to .current like it's a normal version.

[nadako]

you can currently achieve that with haxelib git libname ...; haxelib dev libname; haxelib set git and it seems to work okay

[ibilon]

I remember doing this at some point, never had issues.

It would be nice if you could install it like this haxelib install libname source or dev/git.

Would require a source field in haxelib.json, even if this idea isn't kept the source field would allow to have both github and website link.

[nadako]

Okay, one reason for using dev mode is that it allows to specify subdir to use as a library root inside of a checkout directory. It seems that we easily can't get rid of using devmode for vcs checkouts without losing that feature.

[nadako]

One viable option was discussed in #238:

Only use library as a dev dependency when the subfolder is given.

However I would like to completely remove the feature of using subfolders inside checkouts, it doesn't seem to worth it and it introduces unnecessary obstacles.

This should be backward-compatible in the sense already checked out dirs will continue to work, since they are using .dev files pointing to a subdir and git/hg update should work from within a subdir.

So, let's do this and then remove usage of .dev for git/hg checkouts as described in this original issue?

[ibilon]

I'm all for it.

And it's not like you can't manually do a checkout+dev if you really need it.

[nadako]

We might need to revert 1390259 and stick with "using devmode when subdir is given" because apparently some popular libs can't be installed from git without specifying a subdir: https://github.com/massiveinteractive/mcover/tree/master/src

[ibilon]

That's not exactly something I'd consider good practice, but well too late now.

Another option would be to add a .path file or something that would allow us to alter the output of path, and so let us checkout without using dev after.

[nadako]

Or, we can keep the break, change our CI scripts to use git checkout + haxelib dev and delegate responsibility to library authors, but that's probably not a good thing to do.

[ibilon]

If the feature was new I'd say yes, but sadly it's not the case.

So we need to remove the need of dev while keeping the subdir feature,
would be the best outcome, but could be hard to do that before the rc.

[nadako]

I wonder if we should print a deprecation message when subdir is used, so we can remove that eventually?

[ibilon]

Not sure, since people are using it we could try and make it work without dev mode.

[tobil4sk]

There is another issue with using dev mode for the subdir option, which is that it can be forgotten, leading to a broken installation.

# install a version from git
haxelib git hashlink https://github.com/HaxeFoundation/hashlink.git master other/haxelib/
# then decide to temporarily use a dev version
haxelib dev hashlink /some/path
# unset the dev version, and try to switch back to the git version
haxelib dev hashilnk
haxelib set hashlink git

Now the other/haxelib/ subdirectory we specified when installing has been forgotten and we can no longer use the library properly. This is because manually setting the dev version overwrote the dev version configured when installing the git library.

Storing a file for how a git/hg library was installed would also allow for smarter git installations/updates so that is probably the best solution. The subdir option is useful for a lot of hashlink libraries (hlsdl, hlopenal, hldx, hashlink) and it's been around for a long time so I think it would be better not to remove it.