-
Notifications
You must be signed in to change notification settings - Fork 5
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
Move some plugins into gmod organization? #1
Comments
Discussed with @elliothershberg, note that things like ideogram, gwas, etc all could certainly use more work and add new features so has some maintenance burden |
All the ones listed are currently are just my personal repos |
One related thing I'm wondering is: Should we even consider moving some plugins from external to core? The main one that comes to mind is https://github.com/cmdcolin/jbrowse-plugin-ucsc-api In our discussion of improving data import (re-designing/extending the "Add track" workflows, new ways to add assemblies, etc.) I think it could be great to make this kind of plugin for ingesting UCSC a core part of the product. I feel like the absolute killer feature of UCSC is the amazing data available, not the viz. |
ucsc-api is pretty cool, but sometimes (a) incorporating API based things into core can be difficult because API changes, for whatever reason, could happen and then we ship the built version of our code, and it is difficult to update (b) we also target the longtail of genomics where they might not be on UCSC and instead of targetting that longtail it could be that our "central jbrowse instance" has preloaded ucsc data e.g. for GMOD/jbrowse-components#1870 but that needs a little fleshing out and (c) i have observed not ideal API responses and CORS error before and it may not be super well optimized to fetch all data from UCSC's API |
so, it's tough and definitely worth considering even despite things like that, but it might be better to optimize our "central jbrowse instance" workflow and our ease-of-use to install things from plugin store so that people can install third party plugins easily |
Possible candidates include
jbrowse-plugin-gwas
jbrowse-plugin-biothings-api
jbrowse-plugin-arc-renderer (not listed yet)
jbrowse-plugin-biowasm (not listed yet)
jbrowse-plugin-ideogram
It's kind of intangible just moving organizations, just whether we want to sort of "as a group" adopt these plugins
The text was updated successfully, but these errors were encountered: