This is a Feature Proposal

Description

Currently, attempting to publish a package that exists on the public registry will always fail. This restriction makes sense if we assume that users should (or only want to) store unique packages in codebox and intend to proxy all other requests to the global registry.

I'm new here and not sure if this assumption is intentional and/or a desirable characteristic of this registry solution in particular. If so, please allow me to convince you of a few good reasons to allow configuration of this restriction:

1. overriding or patching public packages. deprecated, poorly maintained, and abandoned packages are all too common on the public registry and pose a huge risk to operational security and stability. allowing organizations to publish new (or override existing) versions of public packages is a good way to mitigate that risk.
2. limiting published packages to certain scopes. organizations may wish to enforce, at the registry level, which scope(s) are eligible for private hosting. this is useful when developers opt to only associate the private registry with certain scope(s) or if an organization needs to maintain several registries, each responsible for a discrete scope(s).
3. deprecating private scopes. very similar to # 2, organizations migrating from an existing private registry solution may wish to continue to provide read-only access to a legacy scoped package and also disable publishing new packages to that same scope.

A naive implementation that would satisfy # 2 & # 3 could be accomplished by adding a new environment variable (eg: CODEBOX_RESTRICTED_SCOPES) formatted as a comma-delimited list of permissible scopes. A simple membership check of this list before the existing unique check should be sufficient.

# 1 quickly becomes non-trivial if the ability to override at the version level is desired as existing checks and processes are limited to the package level.

What do y'all think?