Library name capitalisation issues

[tobil4sk]

This issue is related to #465, however, this is not to do with the haxelib server.

First of all, in some definitions, a project name in haxelib.json has to be lowercase, however this is not really enforced at all when submitting a haxelib.

Windows

On Windows, the following problems exist. There are less than on other systems because the Windows filesystem is case insensitive.

• list always returns lowercase library names
• path uses the capitalisation used in the command. For example, haxelib path someLIB would return:

C:\haxelib-repo\someLIB\0,0,1\src
-D someLIB=0.0.1

Even if the actual library name is SomeLib. This is mainly an issue for the -D flag, as usage of define flags in conditional compilation is case sensitive. The capitalisation of the path itself does not matter on Windows thankfully.

Linux

On Linux, there are more problems:

Let's say you install Console.hx version 0.2.15 (current version as of writing this):

• The library is installed to {haxelib-repo}/console,hx/
• Neither haxelib install Console.hx nor haxelib install console.hx recognise that the newest version is already installed (for other libraries it does)
• haxelib install haxelib.json where haxelib.json contains the dependency either "Console.hx" or "console.hx", it does not recognise that the newest version is installed (for other libraries it does)
• haxelib install file.hxml where file.hxml contains -lib Console.hx it does not recognise that the newest version is installed, but if it is -lib console.hx it does.
• haxelib set Console.hx 0.2.15 attempts to reinstall it, while haxelib set console.hx 0.2.15 recognises that it is already installed.
• haxelib path Console.hx fails, haxelib path console.hx works (same for libpath). By extension, you cannot include it in hxmls via -lib Console.hx, you have to put -lib console.hx
• haxelib update Console.hx does not recognise that the newest version is installed (but does not fail), but haxelib update console.hx does
• haxelib remove Console.hx fails, haxelib remove console.hx works
• haxelib list shows console.hx
• haxelib dev Console.hx [path] creates a new library in the {haxelib-repo}/Console,hx/ directory. haxelib dev console.hx [path] works properly
• haxelib git Console.hx [url] also creates a new library at {haxelib-repo}/Console,hx/, haxelib git console.hx [url] works properly
• haxelib run Console.hx fails, haxelib run console.hx works (if there was a run script that is)

Most of these problems on Linux can be solved by always converting the library name to lowercase to generate the library directory. This might have some backwards compatibility issues which may need to be addressed. That would solve all the linux unique issues leaving only the same ones that are on Windows.

[haxiomic]

This is so comprehensive, I love it, thank you!

[tobil4sk]

Some more info and some more open questions:

With the run command, HAXELIB_RUN_NAME is capitalised however the library was called. This should check the haxelib.json file to get the correctly capitalised name (we open this file already anyway).

However, for list and path it's a bit less straightforward.

For list, how do we check what the actual capitalisation should be? We could check one of the version's haxelib.json file. But theoretically different versions might have a different capitalisation of the library name in the json file. To prevent that, we could check that the name field always remains the same whenever someone submits a library and reject it from being uploaded otherwise. However, that would mean that mistakes couldn't be corrected.

Also, the command haxelib dev Bar could be run on a directory with no haxelib.json, and in that case the capitalisation of the library is lost completely (there is also the case where haxelib.json exists but it is capitalised differently from Bar, so just bar for example). This is a bit of an edge case, however if this changes then the integration tests would have to be changed.

path has the same issue when the haxelib.json doesn't exist. This is mostly a problem because of the define flag added on. Either we would change it to always be lowercase if the file isn't found, or just use whatever the user passes into the command like how it works now.

[RealyUniqueName]

Maybe haxelib should maintain a file with libs list in the root of the haxelib repo.

[tobil4sk]

Or just a single file in the project root for projects with uppercase characters? That way if the project directory is removed manually the file will be removed as well, which seems more manageable to me.

The only problem with adding extra files is that it makes the system more complex and so it should be thought out.

But a solution like that could work. However, a decision has to be made regarding where this name comes from. For example, we could either get it from the first version installed, or update it with each new version. It would be easier if we could be certain (at least from now) that new library releases will not change the "name" field in the haxelib.json.

list can then use this file to work out the name, dev can set it to the name passed in, and path can use it as a fallback in case no haxelib.json is found.

Other package managers such as npm only allow for lowercase package names, which removes a lot of these issues. But I guess we have to workaround what's already been done.

Another thing we'll have to think about, is that on linux, project directories will have to be lowercase from now on. This means that any old uppercase directories would have to be converted in order to work properly. For example:
{repo}/PBKDF2 -> {repo}/pbkdf2
(we could keep track of a .repository-version file in the repository root or something similar, which is also future proof)

And if haxelib is going to have changes like this that will require "reformatting" the repository, it might be worth considering if there's any other large changes that need to be made, so that all the breaking changes come in one release rather than multiple.

[tobil4sk]

In #510 I think I have a working solution to this issue now.

All library directories are lowercase now. This means that everywhere now library names are case insensitive, which solves all the related issues. This requires the .repo-version file and a new fixrepo command to repair old repositories. A warning is also printed when using commands that access the repository if the repository has not been repaired. Technically this warning can be removed on Windows, as there the file system is already case insensitive, but for now I've kept it.

The capitalization of the library name is the version which is used by the haxelib.json file of the last version set as current, and it is stored in a .name file for each library if it is not all lowercase. The only exception to this is that "official" releases installed from the server are deemed as more trustworthy and git/hg/dev versions won't override the file if "official" versions are installed.

• haxelib list will use the version found in the .name, otherwise it just uses the lowercase version of the library name.
• haxelib path uses what is found in the specified version's haxelib.json for the -D flag, otherwise if no haxelib.json is found it falls back to the .name file.
• haxelib run uses what is found in .name when it uses the -lib argument for haxe, so that the library can be found again if an alias is being used for it (i.e. the name used when installing it via dev/git/hg doesn't match what was found in its haxelib.json). However, when it sets the HAXELIB_RUN_NAME variable it always uses the haxelib.json name entry.

I've written quite an extensive list of tests for all these edge cases and tests for the fixrepo command.

[haxiomic]

Thank you for all your efforts on this @tobil4sk <3