Commit 81c50ce8 relates to this ticket

I think that this will need to stay open while @jashankj checks the python part of the project next, so this is likely an umbrella to catch a few PR's.

I want to warn about changing shebang from #!/usr/bin/python3 to #!/usr/bin/env python3 in python scripts (as I see it have already happened in buildnum.py). Per Fedora Python Packaging Guidelines [1] it's forbidden to use env:

Packages in Fedora MUST NOT use /usr/bin/python. Instead packages for Python 3 MUST use /usr/bin/python3 (even if upstream supports both Python 2 and 3). As a result of that /usr/bin/python (as well as /usr/bin/env python and similar) MUST NOT be used in shebang lines or as a dependency of a package. All uses of unversioned python executables in shebang lines will fail the build. These shebangs MUST be fixed.

In Debian it is marked as deprecated [2]:

Maintainers should not override the Debian Python interpreter using /usr/bin/env name. This is not advisable as it bypasses Debian's dependency checking and makes the package vulnerable to incomplete local installations of Python.

The case with buildnum.py is probably fine, since it's a build time script and it's not going to be shipped or used by the end user. But for the rest of the python code, please be aware of this.

[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/
[2] https://www.debian.org/doc/packaging-manuals/python-policy/programs.html

That's a good warning. I'm wondering what's a good portable solution then in this case, because I really don't want to have to template out the #! in the ds python tools. Maybe we have to just require freebsd to do a sed -i post build or something?

At 2020-02-23 08:25:34 +0000, @vashirov commented:

I want to warn about changing shebang from #!/usr/bin/python3 to #!/usr/bin/env python3 in python scripts

OK; I'll back that out. (Ditto the sed vs gsed fix.) But it should be noted that forcing the hardwiring of a particular path to a Python interpreter is also not portable.

(I personally disagree with the Fedora and Debian packaging guidelines because of this, but that's neither here nor there.)

At 2020-03-23 23:15:46 +0000, @firstyear commented:

Maybe we have to just require freebsd to do a sed -i post build or something?

FreeBSD ports does have a mechanism to do that, and I'm putting together a port anyway. I'm not sure I'm happy to rely solely on that, as it means anyone who's just picking up the source tree has more work to do, but it'll do for now.

Is there any reason not to use the @pythonexec@ substitution, given the mechanism is already there? I've already been considering it for patching up a few other scripts where it's not used.

~... Does buildnum.py even need to be written in Python?~
Nevermind, there's no standard and portable way to do that. Ugh!

We try to keep as much as possible in python, it's much nicer than shell scripts, and easier to maintain :)

OK; I'll back that out. (Ditto the sed vs gsed fix.) But it should be noted that forcing the hardwiring of a particular path to a Python interpreter is also not portable.

No need to back out, this change is fine. The warning was about user runnable code.

Is there any reason not to use the @pythonexec@ substitution, given the mechanism is already there? I've already been considering it for patching up a few other scripts where it's not used.

IIRC, it was introduced during python2 -> python3 transition for the scripts that are not part of lib389, where we had to support it on both versions. Now that we support only python3, there is no real need in it.

Unfortunately, I don't have a good solution for this. See also this blog post [1] and PEP 394 [2] for more information about the current (sad) situation with python shebangs.

[1] https://blogs.gnome.org/mcatanzaro/2018/02/16/on-python-shebangs/
[2] https://www.python.org/dev/peps/pep-0394/

We try to keep as much as possible in python, it's much nicer than shell scripts, and easier to maintain :)

FYI, buildnum.pl was ported to python in master branch...

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/4024

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.