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
Ouch, this one hurts. It turns out that PBR-based setup does *not*
install all dependencies when running `python setup.py install`. On the
other hand, running any of:
- `pip install .`
- `pip install --editable .`
- `python setup.py develop`
...makes everything work. So, let's change the instructions and all the
build scripts (including the Docker file) to make sure this thing still
works. Sorry for noise.
This is a significant change, it means that people will have "in-place
installations" of GNPy. Changes to their git checkouts, if used, will
apply, etc. I think this is actually a good change.
fixes#287
TL;DR: package installation with Python is still a mess.
Change-Id: I422b889b599e0b7cae36f160d1548cef7fb50a4e
A third, independent job in Travis CI just for building a container
image (and testing it a little bit). Here's how to use it once it is
built and published and pulled:
$ docker run -it --rm --volume $(pwd):/shared telecominfraproject/oopt-gnpy
One can also pass commands to it directly. Note that the *relative* path
specifier given as `./` is required. One could possibly get around it by
$PATH manipulation, but hey, I have to stop somewhere.
$ docker run -it --rm --volume $(pwd):/shared telecominfraproject/oopt-gnpy ./transmission_main_example.py
Thanks to Jonas for the --volume option trick and for that early
non-overwriting copying for the example directory.
The `install` phase in Travis CI is apparently common for all jobs in
the build matrix (it's rather confusing what they call a "stage" and
what is a "job" for them, and what their mutual relation is). Because
there's no point in doing any kind of installation in case when we're
building for Docker, let's just move the old `install` block into
`script`. With just that, however, Travis adds an implicit `pip install
-r requirements.txt` in an attempt at being helpful. In short, having
completely different "stuff to be done as a check" is very painful with
Travis.
The individual "script lines" in a job's `script` section are always
executed, all of them, even if a previous one failed. That's why I moved
the actual Docker invocation into an external shell script. When they
were not in a shell script and the script lines contained `set -e`, then
a failure of a particular command would cause the build to be marked as
"errored" instead of "failed" within Travis. Also, the multiline if
conditionals were rather painful to write.
One commit might end up in different branches. If that happens, the
second build would overwrite the image tag in the docker registry, which
is rather suboptimal. Let's try to fetch that image first, and only
update the latest/stable tags if the image was already available
beforehand.
fixes#260
