Pangeo Binder for Parcels

[delandmeterp]

This PR provides the yml file that Binder needs to build Parcels,
and a direct link to go the Pangeo Binder

[delandmeterp]

@willirath, I'm not sure to have fully understood the Binder idea. Since it goes with all our source codes, we should provide the yml for Parcels dependencies or for full Parcels?

In xgcm, they provide a yml for the full model, but then source files are not useful...

If we only yml the dependencies, then user needs to run python setup.py install.
Is there some "better" practice?

And of course the example data still need to be downloaded. I haven't found I can write a small setup script in the binder directory (for installing and downloading)

[willirath]

I think postBuild is what you want. At least, this is what I've used in my test repo for providing a parcels-examples binder: https://github.com/willirath/parcels_examples_binder

Instead of integrating the binder functionality here, it might be advisable to have a separate repo that only has what is necessary and uses the conda-forge package. As Binder rebuilds the Docker image that the users are working in every time there's a new commit in master, the separate repo pointing to a stable and released version conda package should result in a shorter startup time and less traffic for the binder infrastructure.

[willirath]

@delandmeterp @erikvansebille I gave you write permissions in the binder test-repo I created a while ago.

[delandmeterp]

Thanks! Yes Indeed, so we should have on parcels only the link to the binder with the examples.

[willirath]

In willirath/parcels_examples_binder#2 I've bumped to the latest parcels release and updated the way Binder launches (uses Juptyerlab and starts at the parcels_tutorial.ipynb). If this is working, I'd suggest

• moving https://github.com/willirath/parcels_examples_binder/ to https://github.com/oceanparcels
• (updating the Readme to contain the right link, of course)
• and using a link to this binder repo in the Parcels README / the website / etc.

[willirath]

• moving https://github.com/willirath/parcels_examples_binder/ to https://github.com/oceanparcels
• (updating the Readme to contain the right link, of course)
• and using a link to this binder repo in the Parcels README / the website / etc.

Release procedure would also need to be updated to contain

• bump the parcels version in the environment file of the binder repo to the latest release on conda-forge.

(Note that this step is necessary because Binder only can be forced to rebuild after the binder-repo itself was changed. Changed dependencies (i.e. parcels on conda-forge being updated) do not trigger updates of what the user sees on binder.)

[willirath]

Ah. I think it's not necessary to use pangeo binder here. Just go for the link in the parcels_examples_binder repo that uses mybinder.org.

[erikvansebille]

This binder is really awesome! Should we also add binder links on all the tutorials at http://oceanparcels.org/#tutorials?

[willirath]

This binder is really awesome! Should we also add binder links on all the tutorials at http://oceanparcels.org/#tutorials?

Yes, I'd go for this (have a launch all on binder button at the top and deep links on all tutorials):

[willirath]

Yes, I'd go for this (have a launch all on binder button at the top and deep links on all tutorials):

Wait, I thought deep links into the same repo would end up on the same instance. This does not seem to be the case. So I'd recommend just adding the launch button / link at the top for now.

[willirath]

xref: https://discourse.jupyter.org/t/how-to-have-multiple-deep-links-all-ending-up-in-the-same-jupyter-instance/2063