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

Add support for launching from OSF Frozen artifacts #216

Open
yuvipanda opened this issue Oct 20, 2017 · 6 comments
Open

Add support for launching from OSF Frozen artifacts #216

yuvipanda opened this issue Oct 20, 2017 · 6 comments

Comments

@yuvipanda
Copy link
Collaborator

I've been chatting with @betatim @mfraezz about being able to launch a binder based on the contents of a frozen (aka immutable) artifact published on OSF. This is awesome and we should do it :)

On the binderhub side, we would have to do the following:

  1. Add a provider for OSF in binderhub, which returns the cache key for a given OSF url (so we know if it has already been built or if we need to build it)
  2. Add support for Adding support for OSF repo2docker#102 in binderhub, so we launch with appropriate repo2docker content providers
  3. Add some frontend detection in JS that tries to figure out which provider to used
  4. Frontend UI to allow users to explicitly pick which provider is being used.

I think that's all that needs to happen here.

@betatim
Copy link
Member

betatim commented Oct 20, 2017

Generally 👍!

Currently URLs looks like: https://beta.mybinder.org/v2/gh/<org>/<repo>/<branch> with this change should we also support other URLs like https://beta.mybinder.org/v2/<provider>/...provider specific stuff here...?

Then you could have https://binder.org/v2/osf/<project_id> and https://binder.org/v2/doi/<some DOI here> etc

@wikey
Copy link

wikey commented Jun 20, 2018

I think this feature would be amazing! A couple of related items to consider:

  • The OSF URL scheme is the same for files in frozen artifacts (called "Registrations") and those in live projects with mutable data. I don't know if you only want to implement connecting with one versus the other, I like both, but wanted to point it out.
  • OSF uses a non-branching version control system with simple sequential numbering of files (https://osf.io/8ednt/?version=3 for instance) so you won't get a .git directory for files stored on OSF itself.

I think the non-git nature of OSF storage is actually a really great reason to consider adding support to binder because it would expand access to the large number of researchers who have learned enough R, Julia, or python to get their work done but who have not dived into the ocean that is git. Being able to switch from matlab to julia or learn your way around rstudio, save the resulting files, upload them to OSF (or google drive, dropbox, box, or any of the other various services OSF integrates with) and be able to transform those files into interactive, reproducible, code environments with binder is quite an attractive prospect.

@betatim
Copy link
Member

betatim commented Jun 20, 2018

Great to hear that someone else also thinks this would be cool :)

IMHO a large chunk of the work would happen in repo2docker which is the tool that does the heavy lifting inside BinderHub regarding cloning and building images. There is a (kinda stale) PR jupyterhub/repo2docker#242 that attempts to refactor the content provider part of repo2docker as a step 0 towards supporting other content providers like OSF or Zenodo. If you want to pick that up let me know!

@jzf2101
Copy link
Contributor

jzf2101 commented Oct 11, 2018

Met people at OSF today. Let's see what they have to say.

@choldgraf
Copy link
Member

Note that @betatim is taking a first step to this here: jupyterhub/repo2docker#242

@manics
Copy link
Member

manics commented Sep 20, 2021

What's the next step here?

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

No branches or pull requests

7 participants