Prevent registration of packages with the same name or UUID as a stdlib

[mbauman]

Unless, of course, it is the stdlib being registered to allow it to become upgradeable.

It would also be good to explicitly prohibit any public Base modules just to prevent confusion (and enable their future extraction into a stdlib, should the case arise). E.g., Core, Threads, Filesystem, etc.

[ericphanson]

I was looking to see where this could be implemented and it seems

RegistryCI.jl/AutoMerge/src/guidelines.jl

Line 303 in 4fae8ef

other_packages = get_all_non_jll_package_names(registry_master)

excludes JLL packages which seems wrong. So we could fix that and add these there (which prevents exact matches up to case sensitivity) and/or add it to the distance check (which raises a flag if the distance is too small). Or add a dedicated new check, since it’s a slightly different case.

[ericphanson]

We currently check against:

• names of non-jll packages and stdlibs for exact matches
• names of non-jll packages and stdlibs for too-close matches

We do not check UUIDs in AutoMerge, but RegistryTools checks it and we only automerge PRs that come from Registrator.

I have a PR in preparation to expand it to include JLL packages for exact matches and add a UUID-based check in AutoMerge. The UUID check should be redundant with RegistryTools, but some PRs do not come from registrator (in which case they need manual verification), and I doubt most folks manually verify no-UUID clashes. So I think it will add safety in that case.

The last case brought up here is public Base submodules. I think it makes sense to add these too, in a separate PR.

[GunnarFarneback]

JLL packages for exact matches

This won't catch anything since all JLL packages contain an underscore in the name and AutoMerge already barks at underscores in names of other packages. (We can of course do it anyway for good measure and some more robustness for future changing assumptions.)