gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ✘Templating


From: Gary E. Miller
Subject: Re: ✘Templating
Date: Sat, 4 Jan 2020 17:04:37 -0800

Yo Greg!

On Sat, 04 Jan 2020 16:47:13 -0500
Greg Troxel <address@hidden> wrote:

> > 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.

Yes, we need to always consider cross-compiling, and packagers packaging
for systems they are not running on.

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

Since gpsd does not do that, not relevant.  Go argue with PEP394
and PEP 397.  Or change the new PYSHEBANG variable to do what ever
you want.


> gpsd has found a particular python version at a particular path at
> configure (scons) time.

Or been told a particular path at configure time.

> It has then arranged to compile .so files

Which are not python, except gps/packet*so which James is working to get
rid of.  So soon a total non-issue.

> against that and to install files into that particular python's
> lib/site-lib place.

Or whereever the builder told scons to put it.

>  So what should be substituted is
> 
>   #!/full/path/to/bin/pythonX.Y

Dunno how you got there.  Not compatible with PEP394 or PEP 397 except
by way of the recently added exceptions, which are discouraged.

> for the particular python found.

Or the python scons was told to use.

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

Uh, lost me.  gpsd has all sorts of version numbers all over the place.
These increase in number as users find new ways to install incompatible
gpsd versions and break things.

We still talking about python?  Pythong requires version numbers for
the site-packages/dist-packages stuff.


> (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.)

Actually, gpsd does not care at all, except for the packet*so which
is going away.  Soon I hope.
 
> As a datapoint, the pgksrc package for gpsd, when built against 3.7
> (default), installs the folowing files:

Which violates python policy in many ways.  I'll just close my eyes
and try to remember I never saw that mess.

> and the first line of xgps is
> 
> #!/usr/pkg/bin/python3.7

And yet, xpgs works on all python from 2.6 to present!  Don't blame
that mess on gpsd!

> 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.

Which is wrong.  It will work with ANY libs built for python 2.6 to
present.  Someone did not read the PEPs.

> 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 yet, it works just great on Gentoo and other distros that read
the PEPs.  Look deeper at Gentoo and understand.

> And if you have to rebuild it
> if you change that, it might as well be explicit so there's less
> magic.

All that magic is not needed.

> In the PEP, see:
> 
>   When packaging third party Python scripts, distributors are
> encouraged to change less specific shebangs to more specific ones.

Out of my hands, do as you wish, but since gpsd is first party, it
does not apply to gpsd as an upstream.

> 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:

Yeah, added after the python guys got sick of fighting some distro guys.

Gentoo does no such thing, and it wworks fine without the extra
complications and contortions.

>       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.

Since gpps python scripts work with all the above, that is pointless.

> 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.

Uh, no.  Gentoo does NOT use /usr/bin/ for the python binaries.  Note
the PEP 395 preferred shenabg:

#!/usr/bin/env python

That python executable can be anywhere, onlye env is in /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.

And yet, Gentoo does not have that restriction because the python in
gpsd does not care at all what python the gpsd modules were built
with, except that packet*so, which is little used.

Don't justify all the extra complexity because early mistakes in your
distro forced it into a corner.

But really off topic.  I just want gpsd to be flexible enough that
distros can do whatever evil thing they want to gpsd without too
much agravation to anyone. 

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

Attachment: pgpSk7ZDYxfus.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]