DOCS: Self-host docs using GitHub pages

[josephmje]

Changes proposed in this PR

• add Sphinx configuration
• update CircleCI config to automatically update docs
• string formatting to Python 3 f-strings
• automatic code formatting as a results of the following VSCode Settings

{
  "python.pythonPath": "/Users/michaeljoseph/.pyenv/versions/datman_venv/bin/python",
  "python.linting.flake8Enabled": true,
  "python.linting.flake8Args": [
    "--config=setup.cfg"
  ],
  "python.formatting.provider": "black",
  "python.formatting.blackArgs": [
    "--line-length=80"
  ],
  "python.sortImports.args": [
    "-sp setup.cfg"
  ],
  "[python]": {
    "editor.formatOnSave": true,
    "editor.codeActionsOnSave": {
      "source.organizeImports": true
    }
  },
  // Configure editor settings to be overridden for [yaml] language
  "[yaml]": {
    "editor.insertSpaces": true,
    "editor.tabSize": 2,
  }
}

To Do

• check that fingerprints are correct in CircleCI config

[codecov]

Codecov Report

Merging #266 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #266   +/-   ##
=======================================
  Coverage   30.66%   30.66%           
=======================================
  Files          56       56           
  Lines        8639     8639           
=======================================
  Hits         2649     2649           
  Misses       5990     5990           

Flag	Coverage Δ
#unittests	30.66% <0.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8f3e344...8f3e344. Read the comment docs.

[pep8speaks]

Hello @josephmje, Thank you for updating!

• In the file datman/dashboard.py:

Line 111:13: W503 line break before binary operator
Line 112:13: W503 line break before binary operator

• In the file datman/scanid.py:

Line 280:5: W503 line break before binary operator
Line 281:5: W503 line break before binary operator
Line 282:5: W503 line break before binary operator
Line 283:5: W503 line break before binary operator
Line 284:5: W503 line break before binary operator
Line 285:5: W503 line break before binary operator
Line 290:5: W503 line break before binary operator
Line 291:5: W503 line break before binary operator
Line 292:5: W503 line break before binary operator
Line 293:5: W503 line break before binary operator
Line 294:5: W503 line break before binary operator
Line 295:5: W503 line break before binary operator
Line 300:5: W503 line break before binary operator
Line 301:5: W503 line break before binary operator
Line 302:5: W503 line break before binary operator
Line 303:5: W503 line break before binary operator
Line 304:5: W503 line break before binary operator
Line 305:5: W503 line break before binary operator
Line 306:5: W503 line break before binary operator
Line 307:5: W503 line break before binary operator
Line 308:5: W503 line break before binary operator
Line 309:5: W503 line break before binary operator
Line 310:5: W503 line break before binary operator

• In the file datman/utils.py:

Line 1008:13: W503 line break before binary operator

To test for issues locally, pip install flake8 and then run flake8 datman.

Comment last updated at 2020-04-21 13:16:08 UTC

[josephmje]

docs are being built here!

[DESm1th]

Not a big deal, but this should probably be one string if on one line now

[josephmje]

thanks for finding this. will fix!

[DESm1th]

Is there a reason to use these specific commits on these repos instead of just the plain old sphinxcontrib-napoleon and sphinxcontrib-versioning?

[josephmje]

the napoleon one has a feature for rending the Parameters header in the docstring that hasn't been merged yet. but I'll remove the versioning one.

[DESm1th]

Nice work! Thanks for putting this together and pushing us toward using the newer style f strings. I think moving forward we should definitely use them, but maybe make an exception and use .format for really large strings though. For me at least it's easy to lose track of variables needed to fill out a large string and accidentally delete or rename something, but format helps a bit in these cases by keeping them grouped at the end. What do you think? Maybe it doesn't make much a difference (it shouldn't if we have tests over code in these instances, haha).

[josephmje]

Nice work! Thanks for putting this together and pushing us toward using the newer style f strings. I think moving forward we should definitely use them, but maybe make an exception and use .format for really large strings though. For me at least it's easy to lose track of variables needed to fill out a large string and accidentally delete or rename something, but format helps a bit in these cases by keeping them grouped at the end. What do you think? Maybe it doesn't make much a difference (it shouldn't if we have tests over code in these instances, haha).

Thanks Dawn. I made the switch the improve readability and cut down on some of the line lengths. But I used an automatic converter to do it and wasn't discriminating between really large strings. That's a good point. I'm in favour of any option that would help with understanding the code.

[DESm1th]

Yeah! I don't think we actually have very many strings large enough for it to matter and none of the strings you updated are all that long. More tests is definitely a better solution than deciding on a case by case basis whether to switch to the better f-string format haha.