[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Fred Wright
Subject: Re: ✘"Can't find packet library")
Date: Wed, 29 Jul 2020 16:36:50 -0700 (PDT)
User-agent: Alpine 2.23 (OSX 453 2020-06-18)

On Tue, 28 Jul 2020, Gary E. Miller wrote:
On Tue, 28 Jul 2020 21:14:27 -0700 (PDT)
Fred Wright <> 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

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 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"

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

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

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

Right, why do we care?

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

Fred Wright

reply via email to

[Prev in Thread] Current Thread [Next in Thread]