Relative links within the source tree work, but they were not being
turned into nice usable hyperlink that go back to GitHub under the
generated documentation.
Reported-by: Melin, Stefan M. <Stefan.Melin@teliacompany.com>
Change-Id: I137ad95fa75a6ee5e1b03a252782e6357d36a3af
In the generated SVG files, there was a '%3' shown as a mouseover
tooltip on mouse hover. Apparently that's what ended up in the <title>
of the whole generated SVG document.
This turned out to be an internal thingy in graphviz/dot. In Sphinx
there's already some support for catching element IDs with this '%3'
madness, but apparently titles are not handled like that.
Solve this simply by providing a title for the whole `graph {}` stanza
in the embedded dot graphs.
Reported-by: Melin, Stefan M. <Stefan.Melin@teliacompany.com>
Bug: https://gitlab.com/graphviz/graphviz/-/issues/1327
See-also: https://github.com/sphinx-doc/sphinx/commit/8494638e45
Change-Id: Ia9f39d13748cdffe74f2cb5032f92c77babb20d8
This was identified during today's coders call where Andrea asked what
the best place for documentation of `sim_params.json` is. Let's split
docs about tangible equipment from those of global "simulation options".
Of course these options are still done in `eqpt_config.json`, which
might get super-confusing to the user -- so please make sure that this
is correctly explained when adding docs for `sim_params.json` in future.
Change-Id: If43894e8f562ca8a768b0efb6cc6c1afeb4aa514
Thanks to Stefan for reporting this.
Reported-by: Melin, Stefan M. <Stefan.Melin@teliacompany.com>
Change-Id: I9ab3aa5f829ffe3ef722df2d46f1393f748a52dc
There are several differences between `python setup.py develop` and `pip
install --editable .` ; one which became relevant a few days ago is the
fact that `python setup.py develop` is apparently happy to pull in
pre-releases of our dependencies -- perhaps due to the fact that this
package, when installed from git, is also considered a pre-release. This
has led to CI failures in Travis, and for some reason just on Python
3.7, not on Python 3.6.
This is of course rather ugly, and there's no need to start pulling in
pre-releases of various pieces of software that we're using, anyway. Fix
this by asking our users to use PIP, and adjusting the CI accordingly.
Zuul CI uses tox which is documented to call PIP behind the scenes, so
there's no change in there.
Fixes: https://travis-ci.com/github/Telecominfraproject/oopt-gnpy/jobs/353680894
Change-Id: I254066b8dc345e23c061a69d55546d48bac6761d
This looks like something that's been "always" part of the Excel guide.
I think it is better placed in the README. After the releae we migth
want to improve the docs even more, but hey, that's something which
should be done after some discussion, not via these commits that I'm
going to self-approve shortly.
Change-Id: Icd73f4bb3a43f1a684ec7a364e4ebcc9b8e6af88
The PowerShellSessionLexer within pygments has troubles parsing the
example as something valid, so let's revert to a generic one.
Change-Id: I188e1d7bf2f7229ad15c1f0443584344fd11bf84
This also moves SimParams handling to a single place. As a result,
path_requests_run has just become Raman-aware (to the minimal possible
extent, OK).
Change-Id: I4e31af5c67335963ddab567d304f48a899cd569e
We agreed that `gnpy.core` should only contain stuff for propagating
wavelengths. Conceptually, JSON parsing and even instantiating these
network elements from data obtained through JSON is *not* something that
is on the same level -- and this will become more important when we move
into YANG format in future.
Also, instead of former `gnpy.core.equipment.common`, use
`gnpy.tools.json_io._JsonThing`. It is not really an awesome name :),
but I think it sucks less than a thing called "common" which would be no
really longer any "common" in that new file.
Change-Id: Ifd85ea4423d418c14c8fae3d5054c5cb5638d283
The TL;DR behind this patch is that it's better to have a utility
conversion function instead of having multiplier LUT and open code which
implements the conversion.
The FiberParams handling looked fishy -- apparently, it was keeping the
multiplier around, but it was unconditionally setting the units to
meters, anyway. Given that the units were not being preserved anyway
(everything got converted to meters), and that the multipler was not
used anywhere, let's refactor the code to just convert to meters using
our new utility function, and remove the unused argument.
Change-Id: Id886d409a4046f980eed569265baefd97db841bd
Image source: I took the existing banner, cropped it and resized to
200px width as per the theme docs.
Change-Id: Ic79b6164d557298746fe878de31ee0a9b0d93923
That class is an internal implementation detail, so mark it with a
leading underscore as per Python idioms.
Also, tweak the docs so that there's less duplicate information and
more cross-references.
Change-Id: Ieb1c8034ab5b442032396d7c4bbd0a697c7eb492
Also make sure that all modules are covered. It seems that there's no
automatic way for doing this, aargh. On the other hand, there's
apparently no need to repeat all the Sphinx markup blurb, and even
sectioning works nicely (read, "as I expect it to work") now :). I think
that it's still necessary to keep these "intermediate files" that only
trigger package-level and module-level autodocs, but hey, I can live
with this.
Change-Id: I705e0054cd7cd4350171770795d69f5c15c226d6
The documentation is something which our users see as one of the first
things when they go and try GNPy. With all respect to people who have
contributed over the years, there are more important information to
convey to a first-time user instead of a list of authors.
Change-Id: Ibe5f6477f9736b9ab71effcf0eccef7c7fdfdde5
It turns out that our current setup does not really support the `sdist`
Python packaging step. I'm trying to increase automation, both for
making releases for upload to pypi.org, and also for CI via Zuul. As it
turns out, Zuul comes with a set of predefined jobs which -- by default
-- use `tox`, and tox was having troubles dealing with our `setup.py`
because it also assumes that the `sdist` step works. It is also supposed
to:
- fix version number duplication in `setup.py`,
- fix version number duplication in Sphinx docs,
- prevent the need to write a `MANIFEST.in` manually.
TL;DR: insetad of having to deal with a ton of other creative
boilerplate, use tools for lazy people like me, and PBR ("Python Build
Reasonableness") appears to check the marks here.
Change-Id: I27c36c4f6b0e76857d16f7819ec237e9b811476a
Docs building started failing after our dependency update. The reason is
that the updated sphinx bibtex extension started being a bit stricter in
their interpretation of bibliography files:
parsing bibtex file /home/jkt/work/TIP/oopt-gnpy/docs/biblio.bib...
Exception occurred:
File "/home/jkt/work/TIP/_py/lib64/python3.6/site-packages/pybtex/errors.py", line 78, in report_error
raise exception
pybtex.database.input.bibtex.DuplicatePersonField: entry with key bononi_modeling_2012 has a duplicate year field
Fix this by using `date` as field name when a full date is given.
I do not have a vector image of this one, unfortunately. The data
apparently comes from "someone at TIP", perhaps a hired graphic
designer. It was passed to me by Diego Landa when I asked for the
original dataset.
These two lists were not synced with each other, and some contributors
whose commits have been merged in git were missing. The resulting list
is a bit longer because not everybody who contributes does that strictly
via commits pushed to GitHub.
* Add Travis-CI configuration for continous integration
* Add GN-Model Documentation and auto-doc integration
* Add GN model to Fiber
* Unit of measure conversion adapted to SI
