ProxyRepoProvider which routes requests to existing repoprovider based on external api #1511
+76
−2
Conversation
This file contains 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
ProxyRepoProvider queries an API endpoint on instantiation with the provided 'spec' as the resource id. The API must return both a 'provider' and an updated 'spec'. Attributes are then copied from the proper RepoProvider. The initializatin returns the proper RepoProvider and updated kwargs
|
Thanks for submitting your first pull request! You are awesome! 🤗 |
consideRatio
changed the title
|
I'm struggling to understand what this class would do from the PRs description, can you clarify with a practical example or similar?
|
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.
What does this do?
This creates a RepoProvider subclass that allows for routing spec resolution through an external API. This has benefits for my use case and may or may not be useful enough to warrant inclusion in binderhub. The most direct use case is that this allows for a dynamic list of allowed repositories #280, which could be useful for organizations that wish to host a binderhub with the ability to regulate repositories that are available.
How else can this be done?
This can be done through extraConfig. Due to
SPEC_NAMESinmain.pyhowever, the repoprovider would have to be routed through an existing provider name, which seems somewhat hacky. Another potential update would be making all references to the list of repoproviders configurable. This might also be related to a solution to #322