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

organize notebooks #2

Open
cehbrecht opened this issue Jan 17, 2019 · 13 comments
Open

organize notebooks #2

cehbrecht opened this issue Jan 17, 2019 · 13 comments
Assignees
Labels
enhancement New feature or request

Comments

@cehbrecht
Copy link
Member

See examples:
https://github.com/ioos/notebooks_demos

@nilshempelmann
Copy link
Member

nilshempelmann commented Mar 18, 2020

@cehbrecht
Organisation proposition:
{bird}_{version}_{process}_{version}_{example/demo/tutorial}.ipynb

@cehbrecht
Copy link
Member Author

@nilshempelmann currently the birds have all there own notebooks. So, this repo is not much used ... we might collect general examples or demos.

@nilshempelmann
Copy link
Member

@cehbrecht: If birds have their own notebooks, the birdhouse tutorials (combining birds) should be here: https://github.com/bird-house/birdhouse-docs, right?

But general suggestion: Moving the notebooks out of the birds would reduce the datasize of the birds. For the longterm, the notebook repository should be used. Opinions?

@huard
Copy link
Contributor

huard commented Mar 18, 2020

@nilshempelmann We're increasingly using the notebooks as integration tests. This means that with each PR, Travis-CI runs the notebooks against the server code to check that a change in the processes did not lead to a failure in the notebooks. In this sense. having the notebooks within each bird is very convenient.

The question now is how to aggregate all those notebooks at a single place in the bird-house documentation.

@nilshempelmann
Copy link
Member

nilshempelmann commented Mar 18, 2020

I get the idea for tests. (serverside)
For tutorials and examples (clientside) code should be easy accessable, having the low bandwidth regions in mind. Downloading a notebook can already be an obstical

@huard
Copy link
Contributor

huard commented Mar 18, 2020

Our strategy is to collect notebooks on our own JupyterLab server.

@nilshempelmann
Copy link
Member

Thats a good startegy. But you still keep them in the bird-repositories?

@nilshempelmann
Copy link
Member

@huard
If I got it right, this here could be a solution to keep a documentation sync with a notebook:
https://nbsphinx.readthedocs.io/en/0.5.1/

@nilshempelmann
Copy link
Member

nilshempelmann commented Mar 18, 2020

@cehbrecht @huard
Checking out the notebooks of raven, I understood that shinx is converting them ... ok, ok ... got it :-)
So the place for bird notebooks is
{bird}//docs/source/notebooks/
and general tutorials:
.birdhouse-docs/docs/source/{tutorial}

This repoitory here is obsolete than... and the issue can be closed?

@huard
Copy link
Contributor

huard commented Mar 18, 2020

One thing that remains to be done is organizing the collection of notebooks from individual birds, and thinking about integration notebooks using processes from independent bird. In PAVICS, we keep those general notebooks in pavics-sdi/docs/source/notebooks, but some of them could be moved to birdhouse. Some of them are specific to the pavics infrastructure.

@nilshempelmann
Copy link
Member

OK, so this could be placed in this notebook-repository or in .birdhouse-docs/docs/source/

@Zeitsperre
Copy link

@nilshempelmann Should we open a PR to do this?

@nilshempelmann
Copy link
Member

nilshempelmann commented Mar 30, 2020

@Zeitsperre This issue is on the low burner, since the notebooks gets organized in the birds.
Here we could e.g establish and collect general tutorials.
A PR might be a bit overdosed since this repository is almost at scratch. Just push into master, finetuning can be done with a PR.

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

No branches or pull requests

4 participants