On Tue, Sep 26, 2017 at 07:30:02PM -0400, Eric S. Raymond via devel wrote: > Gary E. Miller via devel <devel@ntpsec.org>: > > > 2. Gary files a bug upstream to the Python devs detailing how > > > get_python_lib() is implicated in FHS nonconformance. Gary, you > > > willing? > > > > I'm feeling like a broken record. The current behavior is a feature, > > not a bug. You know I love to bash Python, but in this case they > > got it right. > > > > If the user is installing code from source, then it should not > > be executable by default. For the same reason /usr/local/bin is > > not in the standard PATH, the /usr/local/lib/pythonx.x/ is not > > in the PYTHONPATH. > > > > If you are gonna file a bug on PYTHONPATH, you gotta file one on > > PATH. Just don't put my name on it. > > > > And I still feel there is a middle ground here that might work, but it > > is not immediately obvious. > > Are you sure we're still talking about the same problem? > > At this point it looks very much as though: > > 1. Our code was accidentally FHS-correct, but not doing what it should, > which is calling get_python_lib(). > > 2. Fred's patch changed it to do the right thing, call get_python_lib()... > > 3. ...which unmasked an upstream Python bug breaking FHS conformance. > > Does this match your understanding?
Eric, didn't you file a ticket with waf (https://github.com/waf-project/waf/issues/1897) for this same issue in January 2017? Also, waf chose not to use a directory in sys.path in commit https://github.com/waf-project/waf/commit/588f809ffa4dd514ea90bdcd0341d9baf508784f See https://github.com/waf-project/waf/pull/1554 for more background. We could revert that commit in our local waf copy, or we maybe modify the internals in our wscript file... Cheers, -Matt _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
