Hi there,
I just ran into the issue of having a configuration denying the usage of math/rand - with the result of unintentionally also denying usage of math/rand/v2.
- pkg: math/rand
desc: consider math/rand/v2
That can be solved by refining the config to:
- pkg: math/rand$ # We need an exact match, otherwise this rule will also disallow "math/rand/v2"
desc: consider math/rand/v2
But it raises the general question, whether math/rand/v2 should really be denied by the upper rule? My assumption is that depguard basically performs a prefix match - and therefore considers math/rand/v2 a package inside the math/rand module?
I haven't looked into the code yet and am not entirely sure on what the Go specification demands in order to prevent version/package name ambiguity...
Depguard does just do a prefix match. And your solution is the intended solution around the issue. This does have its limitations, but I believe it was worth the performance improvements we get from it.
Hi there, I just ran into the issue of having a configuration denying the usage of
math/rand
- with the result of unintentionally also denying usage ofmath/rand/v2
.That can be solved by refining the config to:
But it raises the general question, whether
math/rand/v2
should really be denied by the upper rule? My assumption is thatdepguard
basically performs a prefix match - and therefore considersmath/rand/v2
a package inside themath/rand
module?I haven't looked into the code yet and am not entirely sure on what the Go specification demands in order to prevent version/package name ambiguity...