server: Dockerfile expects to be run from repository root

[s-heppner]

Currently, the Dockerfile for the server expects to be called from the repository root, as all paths are relative to it:

COPY server/uwsgi.ini /etc/uwsgi/
COPY server/supervisord.ini /etc/supervisor/conf.d/supervisord.ini
COPY server/stop-supervisor.sh /etc/supervisor/stop-supervisor.sh

This is uncommon, as usually paths are given relative to the Dockerfile itself.
What makes this especially problematic, is that we are now unable to build the container from its GitHub path, as there you can only specify the path to the Dockerfile:

services:
  repository:
    build:
      context: https://github.com/eclipse-basyx/basyx-python-sdk.git#main:server

Therefore, I strongly suggest to adapt the paths to being relative to the Dockerfile so that we can build the container directly from GitHub.

[s-heppner]

I'll try to summarize the discussion about this in the dev-meeting here:

First of all, there are two clashing use-cases for the server:

• A user wants to download, build and run our server straight from GitHub (as described in this issue)
• A developer wants to run our server with local changes to either server or SDK to check that everything's working (this is currently implemented)

It is important to point out that the most fundamental design decision, our mono-repository, ensures compatibility between all contained packages "only" for each commit, as each commit is tested with our CI pipeline. This compatibility is something we would not have at all without the mono-repository design and therefore, it would be stupid not to leverage this fact here.

We therefore decided on the following:

In the future, when building the server image, we figure out which commit the image is build with and then install the SDK as dependency with the version of this exact commit, as we know that it'll work and is compatible. We'll hide this somehow in the Dockerfile and additional scripts so that a user can simply use the above:

services:
  repository:
    build:
      context: https://github.com/eclipse-basyx/basyx-python-sdk.git#main:server

with branches like main or develop and the build script for the image will find the respective commit for installing the SDK as dependency.

For the second use-case: "A developer wants to run our server with local changes to either server or SDK to check that everything's working", we decided to use a locally running server without Docker, so directly run via Python. This way, we avoid needing two different Dockerfiles.

Lastly, we need to document this design decision at appropriate places and tell a user more precisely how to use the server in which context.

[s-heppner]

After some more research, we decided on a different solution, due to understanding how Docker builds its containers.

Basically, when fetching the data from this repository, Docker clones the whole repository anyway, therefore the correct version of the SDK is already in the local cache together with the server.
It only makes sense to use this local SDK as dependency when installing the server.

However, this still provides a problem, this time with the local (non-Docker) install, as we cannot specify the SDK dependency in the pyproject.toml (as the version specified there would get installed first and then the locally cached version would likely be skipped), therefore we somehow have to ensure that when run outside of Docker, the local SDK gets installed as well.