Python libs on Debian/Raspbian

[Gary E. Miller]

Yo Richard!

On Wed, 20 Dec 2017 00:35:48 -0600
Richard Laager via devel <devel at ntpsec.org> wrote:

> On 12/19/2017 10:23 PM, Gary E. Miller via devel wrote:
> >> F) .pth file in /usr/.../pythonX.Y/....-packages  
> > 
> > Uh, no.  I looked at this some more.  That first ... can only be
> > lib, lib32 or lib64.  Waf can not write there, Python only looks
> > there.  
> 
> Agreed. We can either tell the user to write there, or violate PREFIX
> (minimally). I advocated the former, Fred Wright advocated the latter.

I'm not sure you mean by 'violate PREFIX'?

> >> G) utilities look at argv[0] path and modify sys.path  
> > 
> > Hmm.  I just tried that, no good.  Here is what I get for argv:  
> 
> So Python is not C-like in this regard. I hadn't actually tested, and
> was mainly using that as shorthand. But it sounds like you've found
> something that works:

Actually, that is C like.

# cat /tmp/tmp.c 
#include "stdio.h"

int 
main( int argc, char *argv[]) {
	printf("%s\n", argv[0]);
}

# gcc tmp.c
# ./a.out
./a.out



> >     os.path.dirname(os.path.realpath(__file__)
> > And funny about the cron, sudo, openrc, etc. environments.  I seem
> > to have no difficulty at all setting environment variables in
> > there.  
> 
> I can set things there too, but: a) it involves duplicating the
> environment variable in multiple places, and b) other people do have
> trouble.

I'm not a big fan of going that way, certainly not by default.

It would really mess up anyone doing non-standard things in ways
he would not expect.  I'd rather stick to the standard module
locations and search rules.


> The more I think about it, the more I'm liking option H (waf puts
> PYTHONDIR into the executables). That Just Works, without requiring
> the user to do anything. It doesn't violate PREFIX even a little. As
> Matt pointed out, it also allows for hard-coding the she-bang to
> match.

Yeah, except it breaks it for people building packages.

A packager installs into a temporary location, tests in that temporary
location, then puts the files in a package that gets installed in 
the distro system location.  Having PYTHONPATH in the executables would
break one or two of those locations.

> It does break if the user moves the python module, but I don't think
> that's a use case worth supporting. Uninstalling and reinstalling is
> always an option. Matt is correct, distro builds would work fine.

I think it is the PRIMARY thing to discuss.  NTPsec needs to be
trivial for packagers to user.

> I personally don't think it is necessary to support multiple versions
> installed simultaneously, but option H should make that work.

Really?  Every time you run regression tests you are running from
a secondary location.  

As soon as distros put NTPsec in their repositories then it will be common
for people installing our git head to have 3 wrking copies: system,
/usr/local, and waf regression tests.

> I agree
> that the in-working-dir unit testing is critical to keep working.

Yup.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20171220/4c4a4d98/attachment.bin>