gpsd-dev
[Top][All Lists]
Advanced

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

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


From: Gary E. Miller
Subject: Re: ✘"Can't find packet library")
Date: Wed, 29 Jul 2020 17:02:38 -0700

Yo Fred!

On Wed, 29 Jul 2020 16:36:50 -0700 (PDT)
Fred Wright <fw@fwright.net> wrote:

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

And breaks the whole Pure Python and FFI concept.  Remember it is not
just Python that uses FFI.  So a non-starter.

The whole point of Pure Python and FFI is that the Python (or other
language) can be totally separate from any binary.  Your branch breaks
that.  So it breaks any packaging of gpsd in pip.

Another reason to move to Pure Python is that distros split gpsd
in dameon and client parts.  Your brnach breaks that.

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

The core code is very similar to what you have.  You saved code by
removing GPSD_HOME abd removing other flxibility.

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

But Pure Python does not.

> This is true of every version of Python on every OS that
> I've encountered.

Time to read up on Pure Python.

> There's absolutely
> no value in having an unversioned location for libgpsdpacket while
> the rest of the 'gps' package is in a versioned location.

I'm finding it to have large value.  I no longer need to rebuild the
C parts for each python version.

> > 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*.

Uh, no.  When distros split python clients out, as they already do now,
this change makes life much easier for them.

Plus, long term, this will be for much more the packet.py.  FFI is
supported by many other languages.  gpsd will suppport FFI on other
languages, and having them look in the python versioned directories
is wrong.

> >> 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'll take a look at that, but as you said, only an oddity.

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

Not needed anymore, I added version checks to packet.py.

> Then again, the version would be wrong only if the
> filename it's loading were wrong, and that's already
> straightforwardly visible.

Sadly, not true on many OS.

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

Which, as Bernd has noted, does not work for him.  So also a non-starter.

> Note that '_name' may be absolute or relative,

Ah, no.  Many python builds demand it be absolute.  That was part of
the problem with the original importado().

Of course, if you actually find a case where the code breaks, please
bring it up.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        gem@rellim.com  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

Attachment: pgpBupTOLtYm3.pgp
Description: OpenPGP digital signature


reply via email to

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