Re: [gpsd-dev] GPSD and the Python 3 transition

[Eric S. Raymond]

Fred Wright <address@hidden>:
> > > In fact, although I'm not a fan of monoversioned shebang lines in general,
> > > given that Python packages are normally installed in a version-specific
> > > location, some means for writing the corresponding shebang lines into the
> > > installed executables should probably exist, at least as an option.
> >
> > I am directly and strongly opposed to this.  Polyglot Python (that is, 
> > capable
> > of running under 2 or 3) is not difficult enough to write that the extra
> > layer of build complexity required to hack in version-specific shebang lines
> > is justified.
> 
> This isn't strictly a versioning issue at all.  The problem is that Python
> packages (including the 'gps' package) get installed into a directory
> within the tree of one specific Python installation, and imports of such a
> package only work when run with that exact same Python installation.  In
> particular, if a package is installed into the default Python and then the
> default Python later changes, Python programs with a generic shebang line
> using that package stop working.

Ah, yes, you're right.  But...

Much of the Python code doesn't require loading libraries at all.
Notably this includes gpscap.py, jsongen.py, maskaudit.py, and
valgrind_audit.py. It makes sense to want these to be polyglot, and
*not* patch their shebang lines, even under your worst-case
assumptions.

One reason I have a twitch reaction to hacking shebang lines is that
the last person who advocated this (and sent a patch which I somewhat
incautiously took) misunderstood the problem and created build
machinery to shebang-patch two utilities that don't do package loads
at all.  I still need to fix this; it's an unneeded wart on a build
that is too complicated by half.

This leaves us with the following: gegps, gpscat, gpsfake, gpsprof,
test_maidenhead.py, xgps, and xgpsspeed. They have all possible 
combinations of depending one one or both of gps and clienthelpers.

But, OK, supposing we patch the shebangs in these.  What problem would this
actually solve?  You say "the default Python later changes", but if that's
the case we don't actually have any guarantee that the old library locations
will continue to exist. For example, on my Ubuntu 15 system:

address@hidden:~/software/gpsd$ ls /usr/lib/python
python2.7/ python3/   python3.4/ python3.5/ 

Notice what's missing?  The 3.x point releases before 4. And 2.6.  And 2.5.
What patching shebangs actually does is make us hostage to distributors'
whims about when a Python point release is no longer interesting.

Better, I think, to bail out gracefully on a failed import with a message
that says you should either reinstall GPSD from source or upgrade to a GPSD
package version matching the system Python.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>