Re: ✘Templating

[Greg Troxel]

"Gary E. Miller" <address@hidden> writes:

> Yo Greg!
>
> On Fri, 03 Jan 2020 09:37:38 -0500
> Greg Troxel <address@hidden> wrote:
>
>> > As requested, many months back, the gpsd revision is now stored just
>> > one place (SConstruct) and all usage of it is now automatic.  
>> 
>> Yay!  Thankf for doing this.
>
> I'm looking at templating the python shebang too.  Currently it is:
>     #!/usr/bin/env python
>
> Should the template be the whole:
>     /usr/bin/env python
>
> Or just the last part:
>     python
>
> PEP 394 used to provide guidance, but has been watered down:
>
>     https://www.python.org/dev/peps/pep-0394/
>
> I still "encourages" the use of:
>     #!/usr/bin/env python
>
> I know that most distros act against the watered down PEP 394.  What sort
> of mangling is common by distros?  Is the ability to substitute
> for python, python2, python3, python2.7, python3.8, etc. all that is
> needed?

First, whether there is or ought to be "python" or "python3" in the path
someplace is an entirely separate issue from what gpsd should do.

My view is that the "env python" approach is fundamentally wrong for
programs that install python libs (.py or .so).

gpsd has found a particular python version at a particular path at
configure (scons) time.  It has then arranged to compile .so files
against that and to install files into that particular python's
lib/site-lib place.  So what should be substituted is

  #!/full/path/to/bin/pythonX.Y

for the particular python found.

Otherwise, absolutely nothing should be written to destdir which has a
specific version number.

(A package that installs a program written in python that only uses
standard  facilities, and genuinely does not care which python it
eventually runs with is another story.  But gpsd is not like this.)

As a datapoint, the pgksrc package for gpsd, when built against 3.7
(default), installs the folowing files:

/usr/pkg/lib/python3.7/site-packages/gps-3.19.90.egg-info
/usr/pkg/lib/python3.7/site-packages/gps/__init__.py
/usr/pkg/lib/python3.7/site-packages/gps/aiogps.py
/usr/pkg/lib/python3.7/site-packages/gps/client.py
/usr/pkg/lib/python3.7/site-packages/gps/clienthelpers.py
/usr/pkg/lib/python3.7/site-packages/gps/fake.py
/usr/pkg/lib/python3.7/site-packages/gps/gps.py
/usr/pkg/lib/python3.7/site-packages/gps/misc.py
/usr/pkg/lib/python3.7/site-packages/gps/packet.so
/usr/pkg/lib/python3.7/site-packages/gps/watch_options.py

and the first line of xgps is

#!/usr/pkg/bin/python3.7

so that even if python3 existed and was repointed to something else,
xgps would still be able to import the 3.7 libs it was built and
installed with.

I don't understand how anyone expects the "env python" to work if python
ends up pointing to anything but the exact python (version and path) the
program was installed with.   And if you have to rebuild it if you
change that, it might as well be explicit so there's less magic.


In the PEP, see:

  When packaging third party Python scripts, distributors are encouraged
  to change less specific shebangs to more specific ones. This ensures
  software is used with the latest version of Python available, and it can
  remove a dependency on Python 2. The details on what specifics to set
  are left to the distributors; though. Example specifics could include:

      Changing python shebangs to python3 when Python 3.x is supported.
      Changing python shebangs to python2 when Python 3.x is not yet supported.
      Changing python3 shebangs to python3.8 if the software is built with 
Python 3.8.


Now, that's about "distributors", but that last one is mostly what I'm
talking about, except that the PEP does not admit the concept of python
being in other than /usr/bin.  Once you have /usr/foo/bin and
/usr/bar/bin because you have two packaging systems installed, you need
to point to the right one because only one has the gpsd libs installed.