daphnelib: improve pyproject.toml and readme

[m-birke]

extending docs
naming project to daphne-lib

[pdamme]

Thanks for this contribution in preparation of making DAPHNE/DaphneLib available on PyPI, @m-birke. That will definitely simplify things for users.

Overall, the changes look good to me, but a few things need clarification to work out of the box. These things should be improved, but as nobody currently depends on them, we don't need to put them on the critical path for this PR, if you want to merge it quickly.

Recommended changes: (can be addressed after merging)

1. I think the setup instructions should clearly mention that the DAPHNE system must be obtained separately. Currently that's a bit hidden as seemingly extra information above. Maybe we could write something like:
   1. "Follow the instructions at ... to obtain DAPHNE". Instead of the links into the detailed docs, I recommend pointing just to the GettingStarted (or perhaps to the section on the Quickstart for users) and maybe to the overall DAPHNE documentation. Othwise, we might over-emphasize certain sub-topics that could lead users astray.
   2. pip install daphne-lib (even though that may sound trivial)
   3. Configuration of environment variables etc.
2. I think the setup instructions should mention the environment variable LD_LIBRARY_PATH, too. When I follow the setup instructions in the container I use for building/running DAPHNE and try to execute the given script, everything is fine. However, when I try it on my host system, I get the following error message: OSError: libantlr4-runtime.so.4.9.2: cannot open shared object file: No such file or directory. That can be fixed by export LD_LIBRARY_PATH=path-to-daphne/lib:path-to-daphne/thirdparty/installed/lib. Then the script works.
3. It would be good to mention that one should use the corresponding (=same) version of daphne-lib and DAPHNE. Otherwise, there could be incompatibilities. For instance, when I try the setup instructions (plus export LD_LIBRARY_PATH=$DAPHNELIB_DIR_PATH:$LD_LIBRARY_PATH) with the v0.2 binary release, then the given script yields ValueError: NULL pointer access. I didn't investigate that in detail, but I assume that the v0.2 binary release and the current DaphneLib Python code are not compatible anymore.

Optional changes: (may not be needed at all)

1. As the package name daphne is already taken on PyPI, and we basically decided to use daphne-lib: Should we also rename our package to daphne-lib/daphnelib? I'm mainly thinking about imports in Python, e.g. from daphne.context.daphne_context import DaphneContext vs. from daphnelib.context.daphne_context import DaphneContext. Otherwise, what would happen if anyone ever wanted to use the unrelated daphne package and our DaphneLib in the same Python script?

[pdamme]

PS: What I forgot to mention...

Required changes: (need to be addressed before the merge)

1. Make the DaphneLib test cases pass again. Currently they fail as TensorFlow prints warnings to stderr that confuse our checks for empty stderr. Actually, these warnings should get silenced by the line export TF_CPP_MIN_LOG_LEVEL=3 in test.sh... (?)

[pdamme]

Okay, the DaphneLib test cases also fail in other PRs, so this is probably unrelated to your changes (would have been surprising anyway). I will look into that problem separately.

[m-birke]

Thanks @pdamme for the review.

I tried to incorporate all recommended changes.

To the optional changes:

It should not be a problem out of several reasons:

1. The unrelated daphne lib is a webserver (supposed usage as CLI) and probably not used together with daphne-lib
2. If both are used together in an installation, the imports are getting resolved correctly, there only can occur a problem if one does sth. like

import daphne

daphne.func()
v = daphne.MyClass()

but it anyway is the proposed (and only possible atm.) method to make full imports

from daphne.... import MyClass

3. we can never assure that there is no name collision with another PyPI project, there could be a project named 'Foobarzumsing' which provides a Python package called 'daphnelib'

[pdamme]

Thanks for addressing the recommended improvements, @m-birke. Regarding the optional comment on the package name: Thanks for the clarification, fair enough. This PR is ready to be merged now.