Using :: usually makes sense for module names, but does it make sense for most distribution names? It isn't friendly for urls or in file names on certain file systems, so when you have a distribution named Foo::Bar it'll have a tar file named like Foo-Bar.tar.gz and extract to e.g. ./Foo-Bar. These path names aren't
round-tripable to the original distribution name... a distribution named Foo::My-Baz would be Foo-My-Baz.tar.gz which could be mistaken for Foo::My::Baz. Similarly you can't use :: in git repo names, and most people want their distribution name as part of the repo name.
As an example: I'm the author of a distribution named Net::HTTP and I have no expectation that it interops with anything else in the Net:: namespace. But I've unfortunately somewhat implied it by using :: in the name. Net-HTTP would have been a name in retrospect. I think it still makes sense for it to contain modules that use :: because it matches with the directory layout you'd typically develop with.
Next time you create a distribution, considering not using :: in the name.
In an ideal world our "depends" would be either distribution names or module names. Each has pros and cons, but either one would be equally fine. Unfortunately we've always consider both distribution names and module names, which can lead to some surprising dependency resolution results (although technically correct).
It would be nice if one day in the future we could switch to just using one or the other. I think most distributions declare their dependencies using distribution names, so it will be easier to reach that future if we encourage all authors to declare their dependencies that way.
Next time you are updating your META6.json consider updating any depenendency names that are a module name and not a distribution to use the distribution name that contains the module.
We want authors to pin their versions, but it can also be useful to still allow non-breaking updates like security fixes. This can't be done with just the version, as v1.5+ will match v2.0 and that isn't what we want. However it can be done using both api and version. For example consider use Foo:api<1>:version<5+>: we avoid using a version range for api (effectively pinning it to a specific major version), but do use a version range for version (which still allows e.g. security patches).
Next time you are versioning your distribution or pinning dependencies, consider using both api and version to provide an improved upgrade experience for your users.
Consider this section of the META6.json file for Base64:
"support" : {
"bugtracker" : "https://github.com/ugexe/Raku-Base64/issues",
"source" : "https://github.com/ugexe/Raku-Base64.git"
},
Users can take advantage of these entries by using zef browse $identity $secion. For example zef browse Base64 bugtracker will open https://github.com/ugexe/Raku-Base64/issues in a browser window. For source specifically the url can also be used to inform zef where to fetch the source from, so I usually add the .git extension to the url so zef can understand how to install from the url directly.
The next time you want to file an issue try using zef browser $distribution-name bugtracker. If it doesn't work maybe you'll end up opening a second issue requesting that this entry be added!