Many fixes and improvements + workflows pass again -> version 0.5.0

[hannahbast]

1. The test workflows now run through again without errors + there is a new workflow that checks the format
2. New Qleverfile for daily build of OHM Planet
3. Add missing from __future__ import annotations so that script also runs for Python 3.8
4. Improve example-queries command, in particular, it can now also handle JSON results
5. Improve output of get-data command
6. More standard pyproject.toml
7. Many small improvements here and there

[Qup42]

The seeding of random in util::get_random_string should be removed because starting with Python 3.11 the first parameter (seed) may not be of the datetime.datetime type. Only None, int, float, str, bytes and bytearray are supported.
The way I understand the docs, a similar behavior can be achieved by calling seed without a explicit seed.

If a is omitted or None, the current system time is used.

[Qup42]

Some further observations and opinions:

• the auto completion now also supports zsh and fish - nice
• I perceive the note to install the auto completion as somewhat pushy.
• The auto completion note is displayed even though my shell is neither bash nor zsh. But I also didn't find a good way to determine the shell that executed the script.
• Having a way to display the version of the script from within the script itself was very good. The current way is to use importlib.metadata.version("qlever"). It could be implemented as a flag --version in 2 lines.

from importlib.metadata import version
parser.add_argument("--version", action="version", version=f"%(prog)s {version('qlever')}")

• The cmdline in pinfo in util::140 can be None. This happens when we inspect a zombie process. I have observed this randomly with apache on elba.

[hannahbast]

@Qup42 Thanks a lot for your comments, Julian. The last two commits tried to address most of them.

Concerning the autocompletion notice: Do you have a better suggestion? Ideally, pip install qlever would activate the autocompletion, but I don't think that's possible. I would be fine with giving a one-time notice but how should one do that? Not giving any notice at all will probably have the consequence that most users don't use the autocompletion.

[Qup42]

Most of the points are fixed.
Regarding the autocompletion notice: I completely agree that showing it at least once is very important. I am not yet aware of a good solution for showing it only once. Maybe one could store it in a file in ~/.config or directly in the directory. But I'll have to think about that topic more.

[Qup42]

Looks good from my side now. I stumbled upon some best practices while researching

• It seems to be more common (but not universal) to only include the SPDX license expression ¹ in project.license. This is more readable and contains the same information.

  [project]
  license = {text = "Apache-2.0" }
  
  [tools.setuptools]
  license-files = [ "LICENSE" ] # Still include the whole license in the build

• A slight tangent: the license is also commonly added as a classifier. There no classifier for the Apache 2.0 license, only License :: OSI Approved :: Apache Software License for Apache 1.1.

• The [build-system] table is strongly recommended. It allows you to declare which build backend you use and which other dependencies are needed to build your project. ²

  For qlever-control this should be

  [build-system]
  requires = ["setuptools >= 61.0"]
  build-backend = "setuptools.build_meta"

  at the beginning of pyproject.toml

Footnotes

1. a machine readable format to specify what (combinations of) licenses apply ↩

2. https://packaging.python.org/en/latest/guides/writing-pyproject-toml/ ↩

[Qup42]

• There are two typos in src/qlever/qleverfile.py::54.
• I think that debugging the packaging of the Qleverfiles was so hard because setuptools doesn't always package exactly as specified in pyproject.toml. The folders build/ and srv/qlever.egg-info/ are to blame. They both record/cache new files that are available by the config. Files that are no longer included by the config are not removed. Files that were included once then are still included in builds even though they shouldn't. Broken configs (that don't include the Qleverfiles) could still seem to work if the files were included before.
• package and package-dir, to my understanding, only describe the python packages (*.py). Non python packages are governed by package-data. (pip install -e . only creates a symlink in the library folder and doesn't do any filtering. It also works without package-data). But this still does not explain your problems with packaging.

[Qup42]

The layout qlever uses can automatically be discovered by setuptools. The two lines can be removed.

Suggested change

	[tool.setuptools]
	package-dir = { "" = "src" }
	packages = [ "qlever", "qlever.commands", "qlever.Qleverfiles" ]
	[tool.setuptools]

[hannahbast]

@Qup42 Thanks a lot for your help, Julian, I am finally merging this now + this is now a great basis for further development.