On 22 February 2016 at 01:56, Fred Wright wrote:
> 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.
I would love to see the port upgraded as well, but given that it's a
maintained port I still hope that its maintainer will respond and do
the commit. (I don't dare to touch it unless Ryan asks for help.)
> 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.
The line "#!/usr/bin/env python" in "/opt/local/bin/xgps" for example
is something that should also be fixed.
On my machine I get:
> xgps
File "/opt/local/bin/xgps", line 644
Base.gpsfields = map(lambda ((label, hook), widget): (hook, widget),
^
SyntaxError: invalid syntax
(Because I use "port select python python3.5" and I don't want to
change that for a number of reasons. But I never used xgps so far, so
I never noticed it.)
> 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.
Indeed. That's the (only) proper thing for the upstream to do.
> 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.
Btw, the port misses some other dependencies like py27-pygtk:
> python2.7 /opt/local/bin/xgps
Traceback (most recent call last):
File "/opt/local/bin/xgps", line 26, in <module>
import gtk
ImportError: No module named gtk
> The latter part first led to a small pushback on the python2_select
> dependency (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,
Replacing the shebang with "#!${prefix}/bin/python2.7" doesn't really
reduce maintainability of the port. The divergence from upstream is
necessary in this case to make sure that the port works for everyone.
> 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).
I completely support attempts to promote the use of python2_select and
to promote compliance with PEP 0394. But not in a way that makes ports
broken for some users and asks for troubles and lots of reported
problems.
This might in fact be less of an issue for Python 2 where version 2.7
is basically the only supported version, so it doesn't really matter
much what you do. But with Python 3 doing the same would certainly
open a can of worms and break lots of ports for many users unless we
decide to stick with a single version of Python 3.
Using (or switching to) "#!/usr/bin/env python2" instead of
"#!/opt/local/bin/python2.7" is not the answer in case of MacPorts.
> Meanwhile, MacPorts hasn't had an up-to-date port of GPSD in almost nine
> months.
I hope that this will change soon.
Mojca
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
