Allow dots and dashes at repo names in labels

[facundominguez]

Bug fix
cmd/gazelle

This PR has label.Parse accept repo names with dashes and dots. gazelle needs it to process bazel repositories that use these characters in repository names.

Fixes #1082

[facundominguez]

Bazel source code does not seem to allow leading dots and dashes in repository names:
https://github.com/bazelbuild/bazel/blob/cbad324d2c8520195d2ddafcabeb2d2ca96da0a1/src/main/java/com/google/devtools/build/lib/packages/WorkspaceGlobals.java#L53

However, when declaring repositories with http_archive I was able to define and reference repositories like -- and ... I tested bazelbuild/bazel@cbad324.

[blico]

Thanks for the fix!

However, when declaring repositories with http_archive I was able to define and reference repositories like -- and ... I tested bazelbuild/bazel@cbad324.

http_archive rules do not create a new WORKSPACE, explaining why you do not see a failure. If you name a go_repository rule .. then you will see:

Error in repository_rule: invalid repository name '@..': workspace names are not allowed to be '@..'

Given that we cannot differentiate between repository rules that create a new WORKSPACE and those that don't, we should match the pattern in Bazel's source code and require repo name's start with a letter.

[facundominguez]

Given that we cannot differentiate between repository rules that create a new WORKSPACE and those that don't, we should match the pattern in Bazel's source code and require repo name's start with a letter.

I feel inclined to argue for the opposite. Given that we cannot differentiate between repository rules that create a new WORKSPACE and those that don't, gazelle must accept leading dots and dashes so it can digest the most repos that might be encountered in the wild.

Perhaps there is some reason for having gazelle being stricter than bazel, which I'm failing to see.

[blico]

Good point, from the perspective of Gazelle's usage of label.Parse it makes sense for it to be less strict. It is possible there are other consumers of label.Parse that would prefer it to be more strict, but it is unlikely.