Yo Richard! On Wed, 20 Dec 2017 00:35:48 -0600 Richard Laager via devel <devel@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
g...@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
pgpuBUtJdFHEj.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
