Languishing GPSD Update

[Fred Wright]

On Wed, 10 Feb 2016, Fred Wright wrote:
> On Sat, 6 Feb 2016, Fred Wright wrote:
>
> > It's been 3 weeks since I posted patches to update gpsd to 3.16 (ticket
> > #50288), fixing #47739 in the process.

Now 5 weeks.  Although this got some attention, it's still in limbo.

General summary:

GPSD is primarily a C package, which also happens to include some Python
programs.  These are actually optional in the upstream version, though the
MacPorts port doesn't include a corresponding variant.  Since GPSD
requires scons to build, it would need Python as a build dependency
anyway, so there isn't much value in a no-Python variant.  Thus, all users
get the Python programs, whether or not they actually plan to use them
(with the exception of two that I made optional in this version due to
their heavyweight dependencies).

The Python code in GPSD is compatible with 2.6 and 2.7, and even with 2.4
and 2.5 if "simplejson" is available, though the dependency is currently
set up for just python27, only because there's no way to allow for
multiple Python versions without either using variants or using the
monoversioned subport approach.  Either approach is additional work that
doesn't really gain much in practice, given that the scons port is
currently dependent specifically on python27 (probably for similar
reasons, since scons itself is compatible with Python2 >=2.4).  And the
monoversioned subport approach (as currently implemented) doesn't even
work for ports that aren't pure Python, since it winds up trying to
install C programs and C libraries in Python-version-specific directories.

Up through version 3.15 (the latest published MacPorts version is 3.14),
the GPSD Python programs just used the generic '#!/usr/bin/env python' as
the shebang line.  They don't actually work with Python3, but in general,
making Python3 the default is likely to cause lots of problems, so that
hasn't been much of an issue in practice.  However, apparently at least
one Linux distro has made Python3 the default, so the 3.16 release of GPSD
changed all the shebang lines to specify 'python2'.  This is exactly the
right thing for any PEP0394-compliant system, where 'python2' is
guaranteed to be some Python2.x, but doesn't necessarily work on OSX.

The only real difference between 'python' and 'python2' on OSX is that
Apple provides the former but not the latter.  I.e., there's always a
'python' command on OSX (regardless of what one does with python_select),
but not necessarily a 'python2' command.  Since some users may not have
set up a 'python2' command (via python2_select or otherwise), I thought it
useful to include a warning in the form of a "port note" in that case.  I
also included an explicit dependency on python2_select (nominally
redundant given the dependency from python27) since I think it's bad
practice to rely on indirect dependencies for direct requirements.

The latter part first led to a small pushback on the python2_select
depndency (which I think I adequately answered), but then some more with
one poster's preference for adding additional patches to inflict
unnecessary monoversionism on the Python programs.  The latter not only
reduces maintainability by increasing the divergence from upstream, but
also represents a philosophical departure from former versions of the
port, solely to avoid encouraging users to make their setups
PEP0394-compliant.

I don't think that encouraging the use of python2_select is a bad idea in
general, given that more Python3-incompatible programs are likely to be
switching to specifying 'python2' as more OS distros switch to Python3 as
the default (though that's not likely for OSX itself anytime soon).  In
fact, it might make sense to add that recommendation to the notes for the
Python2.x ports (expanding the existing notes about python_select).

Meanwhile, MacPorts hasn't had an up-to-date port of GPSD in almost nine
months.

Fred Wright