Old cruft

[Richard Laager]

On 12/08/2017 11:33 PM, Gary E. Miller via devel wrote:
> On Fri, 8 Dec 2017 22:40:55 -0600
> Richard Laager <rlaager at wiktel.com> wrote:
> 
>> On 12/08/2017 09:20 PM, Gary E. Miller via devel wrote:
>>> By Debian rules, ulness you do some sort of over-ride, '.waf
>>> install' should never, ever, install into dist-packages.  
>>
>> You're still misunderstanding. Debian has just renamed "site-packages"
>> to "dist-packages".
> 
> Uh, no.  You have both.

The distro allows for that, generally. But I don't. I have not build
Python itself from source. The point of changing site-packages to
dist-packages is so that a source build of Python itself does not
conflict with the distro-package of Python itself.

> From the Debian doc: https://wiki.debian.org/Python
> 
>     "dist-packages instead of site-packages. Third party Python software
>     installed from Debian packages goes into dist-packages, not
>     site-packages. This is to reduce conflict between the system Python,
>     and any from-source Python build you might install manually."

"from-source" modifies "Python", in contrast to "Third party Python
software".

In other words, if I install NTPsec from source, but using the
distro-packaged Python, it goes to:
/usr/local/pythonX.Y/dist-packages

If I install Python from source, it is obviously not patched to use
dist-packages, and continues to use the default of site-packages. Then
NTPsec from source using that from-source Python, installs to:
/usr/local/pythonX.Y/site-packages

s/site/dist/ is to accommodate building Python itself from source and
installing *that* in parallel to the distro-python.

Installing Python from source on Debian is a corner case, but in any
event, it Just Works.

> Here I see how Debian Python differs from upstream Python:
> 
> https://wiki.debian.org/Python#Deviations_from_upstream
> 
>     "Note that /usr/local/lib/pythonX.Y/dist-packages is in sys.path
>     so that modules not installed from Debian packages can still be
>     accessed by the system Python."
> 
> So, another diffreence in how Debian uses dist-packages unlike how
> Python uses site-packages.

> PYTHONPATH

Not PYTHONPATH, sys.path.

> outside of Debian does not
> include local site-packages by default.

>> Standard:
>> /usr/local/pythonX.Y/site-packages
> 
> Yup, 100% standard, and need PYTHONPATH.

Okay, so upstream Python does not include /usr/local in sys.path by
default. Debian has fixed this obvious error. Fedora said they were
going to (in the bug I linked), but maybe hasn't (per Hal's testing).

I see why there was some desire to install the ntp Python module to
/usr, even when --prefix=/usr/local. I still think that is wrong. Two
wrongs (Python not searching /usr/local by default and ntpsec violating
--prefix) do not make a right.

I again re-iterate my suggestion:
1) Remove the fix_python_config hack.
2) Add a warning if the calculated PYTHONDIR is not in sys.path,
suggesting that the user do one of the following:
  A) Create a .pth file in /usr
  B) Specify --pythondir=
  C) Set PYTHONPATH in their environment

> Got any doc on the .pth file?  All the Python doc I have seen
> refers to PYTHONPATH instead.  

It's one path per line. Here are the docs:
https://docs.python.org/2/library/site.html
https://docs.python.org/3/library/site.html

> And this .pth file would have to be different for different
> distros.

Yes, slightly. The text of the warning can include the correct paths
(both for the contents of the .pth and the place to create it).

> We gotta do this so it works on the most distros we can.

There is no way to make it work out-of-the-box (where
--prefix=/usr/local) on distros that don't have /usr/local in sys.path.

-- 
Richard

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20171209/42fe69fb/attachment.bin>