-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Import DVC remote plugin config schemas from plugin packages #9711
Comments
It makes total sense and it is and was in our plans, but we didn't get to it since there wasn't any demand from the outside. |
@sisp, are you still planning on creating a dvc-plugin/fsspec? |
Not at the moment. It turned out that GitLab's packages API doesn't properly support listing files (which would be necessary for performing garbage collection) and there's a race condition when performing parallel upload of files to a new package which causes an HTTP 500 response, which is annoying behavior. Since DVC (via |
Okay then. I am closing this issue, as we don't have plans to implement this in short to medium term. |
Disclaimer: I'm still learning how DVC's plugin system for DVC remotes works, so please correct me if my understanding is simply wrong.
I'm working on a DVC plugin to natively support GitLab's generic package registry as a DVC remote. While doing so, I noticed that DVC manages config schemas centrally in
dvc/config_schema.py
for all plugins, each of which is implemented in a separate project though. This means, it's impossible to create and use a custom DVC plugin because at least the config validation fails as DVC doesn't recognize the custom plugin. The error I'm seeing when running the partially working test suite is:I don't think a central config schema aligns well with a plugin system. Instead, I believe it would be much better to retrieve the config schemas for the plugins from the (installed and registered) plugin packages, i.e. each plugin should define its own config schema and DVC should combine them at runtime. This approach would make DVC truly extensible - which is the whole idea of a plugin system in the first place (isn't it?).
The text was updated successfully, but these errors were encountered: