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

[Eric S. Raymond]

Fred Wright <address@hidden>:
> Things like regression tests, OTOH, should be run with the target Python,
> for maximum consistency with the intended target environment.

Good rule in general.  In GPSD's specific application context I'd be
willing to let this slip if it bought a large enough reduction in the
build or test framework complexity, because of long experience that
Python version-skew problems are never - ever - related to or revealing of
problems in the GPSD code itself.

A significant part of the reason is that in GPSD-world the notion of
"target Python" is not actually meaningful for anything but a handful
of test and profiling utilities. On the *very* rare occasions that
those have had bugs (I think there have been fewer than a half-dozen
in the entire project history) they have generally been due to
glitches in Python's OS bindings - I think the least rare categories
related to the socket and pty libraries.

> > 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.
> 
> Yeah, I noticed that, though only for valgrind-audit.

Also applies to jsongen.py.in and maskaudit.py.in.

Dammit, I'm going to fix this *now*.

....

Done.

> If the version of Python where the libraries were installed is removed,
> then the libraries were removed with it, and so the install is broken no
> matter what you do.  But changing the default Python *without* removing
> the one where the libraries were installed shouldn't break the install,
> which is what happens with the generic shebang.

To fix this, we'd have to at minimum (a) templatize 7 files (gegps,
gpscat, gpsfake, gpsprof, test_maidenhead.py, xgps, and xgpsspeed).
Then we'd have to add hair to the scons recipe to plug in a specified
Python version as the value of the @PYTHON@ cookie.

I'm resistant to this because (a) the build recipe is cryptic enough
already, and (b) I don't see a big win here.  I know you do because
you're thinking in terms of deliberately having multiple Pythons
installed, but that's a tiny corner case.  Real users never deliberately
change that version, and real users count on their *package system* to
keep GPSD's library synced with the current default version.

Thus, I'm willing to dump the problem on the packaging system.
They already have to deal with this for every single project in the world
that installs Python libraries anyway - that is, declare that a Python
upgrade forces an upgrade to dependent packages.

> If a packaging system decides to support multiple Python versioning by the
> brute-force method of installing multiple copies of the libraries, then it
> would also be useful to have an install target for just those, so that it
> could iterate over Python versions without duplicating installs of the C
> code (or worse, uninstalling the C code if just one Python version were
> uninstalled).

Again, I think you're trying to take over a a job best left to the
package system.  I'm unwilling to pay complexity cost for that.

> Side note:  It would probably make sense to redefine the existing 'python'
> option to mean "include Python code in installs" rather than "use Python
> code at all".  Back when the build system was make-based, it may have been
> useful to have an option to avoid any dependency on Python, but now that
> it's scons-based, Python avoidance is pretty pointless.  In particular,
> it's rather silly to have a Python conditional to handle the case where
> Python is unavailable. :-) If this were reworked, then the regression
> tests wouldn't need to be suppressed in the python=no case.

I'd take that patch.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>