Skip to content
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

Open
cmdcolin opened this issue Apr 5, 2021 · 5 comments
Open

Move some plugins into gmod organization? #1

cmdcolin opened this issue Apr 5, 2021 · 5 comments

Comments

@cmdcolin
Copy link
Contributor

cmdcolin commented Apr 5, 2021

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

@cmdcolin
Copy link
Contributor Author

cmdcolin commented Apr 5, 2021

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

@cmdcolin
Copy link
Contributor Author

cmdcolin commented Apr 5, 2021

All the ones listed are currently are just my personal repos

@elliothershberg
Copy link
Member

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.

@cmdcolin
Copy link
Contributor Author

cmdcolin commented Apr 5, 2021

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

@cmdcolin
Copy link
Contributor Author

cmdcolin commented Apr 5, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants