fix(gopackagesdriver): Improve wildcard package query matching

[Aaronkala]

What type of PR is this?

Bug fix

What does this PR do? Why is it needed?

Improve wildcard package loading (./something/...) when using a custom bazelQueryScope e.g. //.... Currently, the queryFromRequests transformation results in a query like:

bazel query "kind(\"^(go_library) rule$\", attr(importpath, \"^./something(/.+)?$\", deps(//...)))"

which fails to return any results due to the ^ start of string matching. This PR also aligns the behaviour more closely to the "non wild card" behaviour (see) by omitting the ^.

When using go outside bazel, the following query is valid syntax and correctly loads all the packages under ./something/:

package.Load(cfg, "./something/...")

Which issues(s) does this PR fix?

No issue

Other notes for review

[Aaronkala]

The pattern supplied being treated as a regular expression can result in different behaviour if the input happens to contain regexp special characters. Leaving it as is here

[fmeum]

If we change this, let's fix that as well. Could you wrap the import path into regexp.QuoteMeta?

[Aaronkala]

I pushed a commit that escapes both the wild card case and the default case: 23be4f0

But this essentially means that the ./something query won't work at least against the path that we are seeing //something as \./something won't match //something. I'm unsure if this is correct, and/or if the //something paths are only specific to our implementation.

[Aaronkala]

Okay the importpaths it's actually matching against are in the form of github.com/orgname/reponame/something/foo/bar as defined in go_library() importpath

I'll test if importpath_aliases aliases fixes this for us with something like ./something/foo/bar as the alias

[Aaronkala]

Hmm but the query is targetting only importpath 🤔

[fmeum]

Sorry for getting back to this so late, where are we at? Should I take another look?

[fmeum]

What does the actual kind look like in that case that it doesn't match the start of string?

[Aaronkala]

@fmeum all the returned results without "^" start with // for example:

//something/foo/bar/foobar:baz
//something/foo:bar
//something/bar/foo:baz

I'm not sure if this is what you mean by "kind"

[fmeum]

Thanks, I thought this also affected the usage of ^ in the kind part of the query, but it doesn't.