Allow configuring the Python interpreter

[KucharczykL]

Hi, this PR make it possible to set the Python interpreter using ~/.config/daps/dapsrc or in DC file. Environment variable is not respected which seems to be true for all DAPS configuration options for some reason.

PYTHON=".venv/bin/python"

I did not add --python or any similar command-line arguments.

This makes it easier to package for systems like NixOS, or to make it easy to use different than system Python in case something breaks (case in point: Tumbleweed recently removed the python311-lxml package, breaking DAPS, see https://suse.slack.com/archives/C02DEAP3U5P/p1788274848540109).

I tested building on Tumbleweed and NixOS. There's a package using this change in https://build.suse.de/package/show/home:LKucharczyk:branches:Documentation:Tools/daps but currently blocked.

[fsundermeyer]

Thanks a lot Lukas!

I am not sure what to make of this--it is unobtrusive, but somewhat "hackish".
IMHO the problems you are describing for Tumbleweed and NixOS look like packaging problems to me that should be resolved on a packaging level, not within the code. (The problem you are describing for Tumbleweed can be solved via spec file. the update will be published soon with 4.0~beta16).

@tomschr What is your take her?

BTW: The fact that environment variables are largely ignored is on purpose, Also somewhat hackish, I probably should re-visit this.

[tomschr]

I was also unsure, so I asked Gemini and let them review this PR. Here is what it said:

While I understand the perspective that this is a "packaging problem," I believe this change provides a necessary escape hatch for users and developers. Here's why:

1. User Empowerment: It allows users to immediately work around system-level issues (like the Tumbleweed lxml problem mentioned in the PR) without waiting for a package fix.
2. Developer Flexibility: It makes it much easier for developers to use DAPS with Python virtual environments (venv), which is a standard development practice.
3. Improved Portability: It helps DAPS run on non-standard systems like NixOS, where hardcoded shebangs are often problematic.

The solution is not "hackish." It's a common and pragmatic approach for tools that depend on external scripts. By making it a configurable option that defaults to the old behavior, the change is unobtrusive to existing users.

In my opinion, this PR makes DAPS more robust and developer-friendly. I would recommend leaving a comment in support of merging it.

[KucharczykL]

I am not sure what to make of this--it is unobtrusive, but somewhat "hackish". IMHO the problems you are describing for Tumbleweed and NixOS look like packaging problems to me that should be resolved on a packaging level, not within the code. (The problem you are describing for Tumbleweed can be solved via spec file. the update will be published soon with 4.0~beta16).

In the end the packager will always have to make changes to the software to adapt it to the particular system but this makes it easier.

What exactly do you consider hackish? I can try to fix it if needed.