[breaking] Allow registering packages with missing dependencies #103
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It commonly happens that someone wants to register 2 or more related packages that depend on each other. Because Registrator.jl enforces all dependencies are registered at registration time, this means one needs to serially wait out the dependency tree (or do tricks like rm the dep, register, start the 3 day wait, then add the dep and re-trigger registration). Community review can proceed in parallel so I think it's totally fine to register with unregisterd deps; they will fail the "package can load check" in RegistryCI which is the ultimate check, but you can at least start the waiting period. The mechanism I propose to do that is to remove the check from `registrator_errors` which are meant to be the ones enforced by Registrator, then update Registrator to use this new version. Registrator does not pass any kwargs to `register` so it uses the defaults: https://github.com/JuliaRegistries/Registrator.jl/blob/b468d1955fe239d6229f1e4f4fd1a4a1ec2a4339/src/RegService.jl#L36. An alternate path would be to update Registrator.jl itself to own the kwargs it uses and stop passing this one. That seems reasonable to me but as they are currently owned by RegistryTools the simplest (and lowest effort for me) fix is to update them here. This is probably breaking though as it changes the defaults. Not sure that matters, RegistryTools surely does not have many dependent packages.
ericphanson
changed the title
|
@GunnarFarneback pointed on Slack that the sources feature could allow loading with unregistered deps, so the current RegistryCI checks are insufficient and this check is load bearing. This would need to be paired with a new RegistryCI check that all deps are registered. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It commonly happens that someone wants to register 2 or more related packages that depend on each other. Because Registrator.jl enforces all dependencies are registered at registration time, this means one needs to serially wait out the dependency tree (or do tricks like rm the dep, register, start the 3 day wait, then add the dep and re-trigger registration). Community review can proceed in parallel so I think it's totally fine to register with unregisterd deps; they will fail the "package can load check" in RegistryCI which is the ultimate check, but you can at least start the waiting period.
The mechanism I propose to do that is to remove the check from
registrator_errorswhich are meant to be the ones enforced by Registrator, then update Registrator to use this new version. Registrator does not pass any kwargs toregisterso it uses the defaults: https://github.com/JuliaRegistries/Registrator.jl/blob/b468d1955fe239d6229f1e4f4fd1a4a1ec2a4339/src/RegService.jl#L36.An alternate path would be to update Registrator.jl itself to own the kwargs it uses and stop passing this one. That seems reasonable to me but as they are currently owned by RegistryTools the simplest (and lowest effort for me) fix is to update them here.
This is probably breaking though as it changes the defaults. Not sure that matters, RegistryTools surely does not have many dependent packages.