Docs on website are behind docs in source code

[JobLeonard]

For example, the API walkthrough page still mentions GeneName as an attribute, but in the source of the documentation this has already been corrected to Gene.

This actually indirectly led to an issue with the loom-viewer (although it does not seem to be the core problem)

EDIT: I guess you're the only person with the proper set-up to generate the docs right now, Gioelle?

[gioelelm]

I propose we start using automatic doc building through travis-ci.

There is a library that is meant to deal with it:
https://github.com/Syntaf/travis-sphinx

[gioelelm]

I solved this with what I think is a more elegant and definitive solution than what we had before.

I setup the repo to have continuous integration through TravisCI and I use it to built the docs automatically upon any new commit. Importantly I also added ad edit button all the pages of the docs, allowing easy editing and correction.

The deployment will gets served as a website. Unfortunately right now the url is http://linnarssonlab.org/loompy/ but it would be nice to redirect it to loompy.org/loompy . @slinnarsson can you redirect that url in some way? I guess not right? We are bound to the limit one organization one github-pages url, isn't it? Anyway let me know how you prefer to have it setup, I can always do something more hacky/indirect like this but I would like to avoid.

The possibilities with TravisCI don't end here. Right now we have a job structure with one build and two deployments (see the.travis.yml file to the repo for the full description of the job):

• A deployment of the documentation directly to the gh-pages branch.

• A deployment for pypi, triggered with a new release. That is done simply by tag creation (git tag 1.0 -m "New tag") and push (git push --tags) at any point.
  Notice that there are some rules to respect: __version__ and the number of the tag need to correspond, numbering needs to be update monotonously, and one tag can be set only once and not modified.

I recommend for the future we use Travis for further interesting automations:

• Testing. Of course, this is what TravisCI is mainly meant mainly for...
• Automatically modify our conda recipees on both our conda-forge package and bioconda package (yes, we have two actually).

(Just for future reference for conda package upload: since we have the sbuild on pypi we need only this steps (1) Running a script that changes 2 lines in the meta.yml file: namely the version number and the sha256 of the pypi tar.gz (2) committing to the forked repo (3) Making a new pull request to the master repo. (4) Wait that conda-forge and bioconda do their magic

[slinnarsson]

I updated the docs and thanks to @gioelelm work setting up Travis CI, the docs flowed into the web site just fine!