Re: ✘gpsd is now Pure Python!

[Fred Wright]

On Wed, 25 Mar 2020, Gary E. Miller wrote:

> Thanks to JamesB192 the gps python modules are now Pure Python.
>
> That means one python module works for all python versions, 2.7 and up!
> No shared library files needed.  Removing a long standing annoyance of
> the python module.

Well, the "long standing annoyance" was just due to a confused build 
procedure.  But this looks like a useful cleanup, and a reasonably 
standard approach AFAICT.

> If you have any old packet*so files laying around, you should delete
> them.
>
> The install location is the same as before, but that should be changed
> to a non-version specific location.  Not sure what the best location
> should be.

Actually, no.  Even pure Python modules have .pyc/.pyo files generated by 
Python itself that are version-specific.  Even without Python2 naming 
collisions (Python3 started using versioned naming), there's still the 
issue of creating and installing those at build/install time.  Normally, 
users don't have write permissions for these files, so unless they're 
installed initially, every import has to recompile the modules from 
source.  I never checked to see if GPSD is currently doing this correctly, 
but even if it's not, it wouldn't be a good idea to do anything that would 
preclude fixing that in the future.  Given that those files should be 
installed for every supported Python version, anyway, there's no real 
benefit (other than saving a little disk space) in storing the .py files 
in an unversioned area.  And AFAIK, storing Python modules in an 
unversioned area would be completely nonstandard.

It doesn't make sense for the project's own build procedure to handle 
installing for multiple Python versions.  Even if it did so, it could only 
install for the Python versions available at the time of its install.  If 
another Python were installed later, the additional files wouldn't be 
created automatically.  If this were to be handled automatically at all, 
it would need to be done by the packaging system.  But it's more common 
for packaging systems to install for specific Python versions, possibly 
done in a way that permits multiple versioned installs.

The main thing a project like GPSD needs to do is to provide appropriate 
build/install targets so that a packaging system can treat the Python 
modules as a separate package if it so desires (without requiring it to do 
so, or requiring it to know about individual components).

> As always, please test.  It is a big change and likely something more
> needs to be done.

It currently fails on all macOS versions, because "3.20.1~dev" isn't a 
valid library version number.  And shared library version numbers are 
supposed to be based on API versions, not code versions, anyway.

Excerpt from the version-check comment in SCons (presumably trying to 
match Apple's requirements):

    Check that the version # is valid.
    X[.Y[.Z]]
    where X 0-65535
    where Y either not specified or 0-255
    where Z either not specified or 0-255

Even on platforms that don't choke on the "~dev", actually having 
libraries with that in their filenames seems like a bad idea.


For future reference, it would be far better for inadequately tested 
changes not to be pushed to the master branch, since they create permanent 
potholes in the history that make bisecting difficult.  It's completely 
trivial to push to a test branch instead, and only merge to master when 
"ready for primetime".

Fred Wright