Re: [gpsd-dev] Python Shebang Lines

[Fred Wright]

On Tue, 27 Dec 2016, Gary E. Miller wrote:
> On Tue, 27 Dec 2016 15:02:07 -0800 (PST)
> Fred Wright <address@hidden> wrote:
[...]
> > I think I explained in quite a bit of detail why multi-version
> > compatibility is not the same thing as not caring which version is
> > *currently* in use.
>
> Yes, and I did not bother tpo answert point by point since IMHO you
> overcomplicated it.  As I said, ntpsec has zero issues with mulit-versions
> of python, no matter how you want to permute the issue.

If by "overcomplicating" you mean explaining the problem in detail, then I
plead guilty. :-)

[...]
> Well, ntpsec gets built on about 2 dozen different distros, including
> OS X.  So the corner cases are hidden deep.

Try the following, on any system with more than one Python available:

1) Build and install ntpsec.

2) Change the default Python.  This typically means just changing the
/some/bin/dir/python symlink, perhaps with a tool or perhaps manually.

3) Try some ntpsec Python-based tool that needs pylib.

> > In any case, what I've currently implemented doesn't *require*
> > non-generic shhebang lines; it simply provides a mechanism to have
> > them without requiring the user or packaging system to know what
> > needs to be patched.
>
> Better yet, make it so nothing needs to be patched, ever.

Sure.  All you have to do is to make sure that the Python libraries are
built and installed in every version of Python that *might* be selected as
the default Python (and if you want to be *really* thorough, every version
of Python that might be installed and selected in the future :-)).  Now
*that's* overcomplicated.

There are two important differences between Python and C in this context:

1) With C, libaries normally have the same install location regardless of
which compiler was used to build them.  With Python, libraries have a
different install location for each Python install.  One might argue that
that's a bad design, but that's the way it is.

2) With C, the compiler version is only relevant at build time.  With
Python, the interpreter version is selected at runtime, and *not* by the
program if it uses the generic shebang line.

The combination of the two makes Python library existence a moving target
unless the program is bound to the Python version chosen at install time.

> > BTW, I looked at what SCons itself does on a variety of platforms, and
> > found that Linux is the *only* platform where it uses generic shebang
> > lines, and even that will have to change on any distro where the
> > default Python is Python 3.
>
> I have not found that scons needs any change to run on Python 3.

It doesn't (yet) "run on" Python 3 at all.  The reason it runs on systems
where Python 3 is the default is solely because it uses a shebang line
selecting some form of Python 2.  E.g.:

MacPro:~ fw$ head -1 `which scons`
#!/opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7
MacPro:~ fw$ python3 `which scons` -h
scons: *** SCons version 2.5.1 does not run under Python version 3.5.2.
Python 3 is not yet supported.

The last time I looked, BSD installs of SCons used:

#!/usr/bin/env python2.7

Fred Wright