Re: ✘"Can't find packet library")

[Fred Wright]

On Tue, 28 Jul 2020, Gary E. Miller wrote:
> On Tue, 28 Jul 2020 21:14:27 -0700 (PDT)
> Fred Wright <fw@fwright.net> wrote:
>
> > It makes more sense to install this library in the Python package
> > directory, with the other modules.
>
> Is there a problem that this fixes?

It means that, instead of having some complicated code that took 
considerable research to get to work on two OSes, and which may or may not 
work on some other OSes, the entire body of importado() is now just four 
lines with no conditionals.  In fact, if one didn't care about line length 
or readability, it would be a one-liner.

Not only has this code been tested on a wide range of Python versions and 
OSes, but it's so simple and straightforward that it's unlikely not to 
work on Python and/or OS versions that it hasn't yet been tested on.

In general, any time one can make code simpler without sacrificing 
functionality or performance, that's a plus.

> The problem with this change is the python package directory is
> versioned by python version.  We don't want to install the same thing 7
> places.
>
> Part of the reason to do this is  to have one version that cares not
> about python version.

Python always expects packages to be installed in versioned locations. 
This is true of every version of Python on every OS that I've encountered. 
While it's annoying when the code doesn't really have to be 
version-specific, it's the Python Way (tm), and attempting to do something 
different is like swimming upstream in a flash flood.

And even if one supposed hypothetically that there's an acceptable 
unversioned location for the 'gps' package, then it would *still* make 
sense to store libgpsdpacket in that place.  There's absolutely no value 
in having an unversioned location for libgpsdpacket while the rest of the 
'gps' package is in a versioned location.  In short, storing libgpsdpacket 
outside the 'gps' package directory has zero benefit in all circumstances.

> Also, when installing a daemon only gpsd, there is no versioned
> python directory yto install it in.

Huh?  The whole purpose of libgpsdpacket is to support packet.py.  If 
you're installing without Python, libgpsdpacket shouldn't be installed *at 
all*.

> > And it's a whole lot
> > easier to find when it's "beside" packet.py.
>
> Is finding it a problem?  Seems to work fine now.

See above.

> > I tested a fix that does this, and pushed it to a test branch
> > (pylib-fixes).  Feel free to test further.
>
> I'll look at it, but I'm not excited about it.
>
> > There is an oddity which is just aethetic AFAIK.  Its own internal
> > copy of its path is still based on the usual install location,
>
> How do I see that?  I would like to be able to see that so the Pure Python
> can confirm libgpsdpacket is the matching version.

On the Mac, it's with "otool -L".  I'm sure there's some equivalent on 
Linux.  Note that this is the same "install name" that had some fiddling a 
while back for libgps.

I don't think there's a way to check this that would be suitable for 
direct incorporation into the code, but there might be something a test 
could do.  Then again, the version would be wrong only if the filename 
it's loading were wrong, and that's already straightforwardly visible. 
Not only is that just @GPSPACKET@, but the name of the file actually 
loaded into the CDLL object (not its embedded install name) is visible as 
the latter's '_name' attribute.  E.g., from the build tree:

> > > import gps.packet
> > > gps.packet._packet._name
'gps/libgpsdpacket.27.0.0.dylib'
> > >

Note that '_name' may be absolute or relative, but when relative it's 
valid for the directory where the import happened.  E.g., with an 
installed version for MacPorts Python 2.7 on the Mac:

> > > import gps.packet
> > > gps.packet._packet._name
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gps/libgpsdpacket.27.0.0.dylib'
> > >

> > and I
> > haven't figured out how to convince SharedLibrary not to do that.
> > But since nothing actually links against this library, it shouldn't
> > matter.
>
> Right, why do we care?

As I said, it's mainly aesthetic, and something to be fixed later.

Fred Wright