fix(start-stack): fix outdated TTL paths, open config file correctly (DEV-2497)

[jnussbaum]

No description provided.

[linear]

DEV-2497 DSP-TOOLS: start-stack: TTL paths are outdated, config file is opened in a non-portable way

On Flavie's machine, the start-stack command gives the following error message: Cannot start DSP-API: Error when creating graph 'http://www.knora.org/data/admin'. The logs of DSP-TOOLS don't provide more information.

The Docker container of Fuseki shows that some of the graphs can be created, but then this one fails:

2023-07-26 14:38:35 14:38:35 INFO  Fuseki          :: [8] POST http://0.0.0.0:3030/knora-test/data?graph=http://www.knora.org/data/admin
2023-07-26 14:38:35 14:38:35 WARN  MediaType       :: Duff parameter: charset: utf-8 in text/turtle; charset: utf-8
2023-07-26 14:38:35 14:38:35 ERROR Fuseki          :: [line: 7, col: 11] Bad character in IRI (space): <!DOCTYPE[space]...>
2023-07-26 14:38:35 14:38:35 INFO  Fuseki          :: [8] 500 Server Error (27 ms)

On the maintainer's machine (where DSP-TOOLS is executed from inside the repo), everything works fine.

Analysis

• The paths in _load_data_into_repo() are partially outdated, see https://github.com/dasch-swiss/dsp-api/tree/main/test_data
• On Flavie's machine, the url_prefix is not determined correctly, so it falls back to main branch, so the paths in _load_data_into_repo() are outdated. On the maintainer's machine, the url_prefix is determined correctly, so the paths in _load_data_into_repo() still work.
  • Path("src/dsp_tools/resources/start-stack/start-stack-config.yml") doesn't work on other machines! Use importlib.resources instead!
• ttl_text = requests.get(self.__url_prefix + ttl_file, timeout=10).text is problematic: if the path is outdated, the text is an error message instead of the file content. This error message is then sent to Fuseki, instead of the expected file content, which results in a weird error message.
• logger.error(f"Cannot start DSP-API: Error when creating graph '{graph}'. response = {response}") is not very helpful. The requests.Response object doesn't have a useful repr/str method, so the interesting parts of that object are not printed. → vars(response) gives more info.

[BalduinLandolt]

sorry, I forgot to inform you about this change