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 _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
