dnf traceback when running Python with -P

[jrohel]

I found a problem while creating PR #2074 . dnf traceback when Python is started with -P. I added -P to the shebang line.

-P - Don't automatically prepend a potentially unsafe path to sys.path such as the current directory, the script's directory or an empty string.

# dnf
Traceback (most recent call last):
  File "/usr/bin/dnf", line 61, in <module>
    from dnf.cli import main
  File "/usr/lib/python3.12/site-packages/dnf/__init__.py", line 30, in <module>
    import dnf.base
  File "/usr/lib/python3.12/site-packages/dnf/base.py", line 29, in <module>
    import libdnf.transaction
ImportError: dynamic module does not define module export function (PyInit_libdnf)

Problem is caused by the nasty hack (in "dnf.in", "dnf-automatic.in"):

else:
    # git checkout
    import os
    dnf_toplevel = os.path.dirname(here)
    sys.path[0] = dnf_toplevel

How about removing it?

[ppisar]

I agree with removing the else branch. It's there to support executing dnf from a git tree, but it damages sys,path[0] whenever somebody install dnf into a path different from /usr/bin. This developer-oriented hack should not exist in a production code. Developers should set PYTHONPATH from environment (or with a wrapper) instead.

(Alternatively the hack should prepend a zeroth argument of the program to sys.path instead of rewriting sys.path[0].)