binderhub icon indicating copy to clipboard operation
binderhub copied to clipboard

Add support for launching from OSF Frozen artifacts

Open yuvipanda opened this issue 8 years ago • 6 comments

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 https://github.com/jupyter/repo2docker/issues/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.

yuvipanda avatar Oct 20 '17 18:10 yuvipanda

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

betatim avatar Oct 20 '17 18:10 betatim

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.

wikey avatar Jun 20 '18 18:06 wikey

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 https://github.com/jupyter/repo2docker/pull/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!

betatim avatar Jun 20 '18 21:06 betatim

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

jzf2101 avatar Oct 11 '18 03:10 jzf2101

Note that @betatim is taking a first step to this here: https://github.com/jupyter/repo2docker/pull/242

choldgraf avatar Oct 15 '18 15:10 choldgraf

What's the next step here?

manics avatar Sep 20 '21 18:09 manics