In tox v4, "reuse of environments" was disabled [1]. This is then later
explained [2] to refer to exactly that thing which we were using for
inheriting the dependencies from the top-level testenv all the way to
the docs build. That's why the docs build in GitHub CI started failing.
IMHO, The Correct Way™ of specifying what dependencies are used for
which feature are the so-called "extra dependencies". Once they are in
place, it is be possible to install gnpy via, e.g., `pip install
oopt-gnpy[docs]`. However, this process is (as far as I can tell)
incompatible with `requirements.txt`; all my attempts at using the
standard dependency syntax in that file have failed for me.
So, in order to make this happen, let's move all the dependencies from a
more-or-less ad-hoc collection of files to this declarative approach
right in setup.cfg. That way, the deps are listed on a single place, in
a declarative manner, and as a result, the installation is now a trivial
pip oneliner.
As a result, one can also remove that duplication of dependencies in
docs requirements.
[1] https://tox.wiki/en/4.11.4/upgrading.html#reuse-of-environments
[2] https://tox.wiki/en/4.11.4/upgrading.html#packaging-configuration-and-inheritance
Change-Id: I34aa0c71e993b39e2b805a7de40e133b4d290318
Fixes: 47c89626 fix docs requirements
The examples have lived below gnpy/example-data/ for a few releases
already, and I've checked that these files are included in release
tarballs and wheels.
Change-Id: I782fc56a171f4cbc08f6698ac5d339e4cacecbb4
The CI is (so far) only post-merge via the GitHub CI. The Zuul CI is
pending on Fedora 35 images within nodepool; I've requested that via a
ticket at Vexxhost, our hosted CI provider.
Change-Id: I81c9867792f972db8fcb2bf902f5f8d1ed7ffeea
Our landing page on PyPI was not displaying the longer version of the
README, just a one-sentence summary. It turns out that `pbr` can indeed
read the README file, but specifying the `description` overrides that
with no warning. Yay.
Change-Id: Ic03412928fe09f5edab4a7b9f4297a485a740cd0
We discussed this at one of the recent coder calls; the motivation
includes better mypy type hint support, especially in numpy, but also in
the language core, and of course the dataclasses.
Change-Id: I8ffee28c33f167cbcba978c85486e58a1b8c99be
We've been testing with Python 3.9 via Travis since this February, so
let's mark the project accordingly. Once a release which contains this
commit gets uploaded to PyPI, it will be propagated to the pip's web
interface.
Change-Id: I84635157565f1dbe9936231fa32ef3f6a0605e2f
Esther mentioned that it is useful for her to be able to convert from
XLS files to JSON files. Let's add a full blown script for this.
I've also taken the liberty to refactor the code a bit so that there's
no default value, and to modernize everything with pathlib a little bit.
Change-Id: I80e50fc1280003910242ce1ff9fc9ae66e6d275b
I would like to create a package for distribution to PIP, and this seems
like the path of least resistance.
This is, apparently, the way for shippign arbitrary data with Python
[1]. I've at least tried to make it user-firendly via adding a simple
utility which just prints out whatever that data path is.
[1] https://python-packaging.readthedocs.io/en/latest/non-code-files.html
Change-Id: I220ecad84b1d57d01e3f98f15befc700bd97c0b8
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
