>> Having a PYTHONPATH setup could be leftover from when
>> ntpsec needed it, or it could be setup because some other
>> package needs it.
> Most likely the former, since reasonable packages don't
> require PYTHONPATH. :-)
It seems reasonably likely to me that anybody geeky enough to be inst
Yo Fred!
On Sat, 7 Oct 2017 12:36:41 -0700 (PDT)
Fred Wright via devel wrote:
> On Sat, 7 Oct 2017, Gary E. Miller via devel wrote:
> > On Sat, 7 Oct 2017 12:15:27 -0700 (PDT)
> > Fred Wright via devel wrote:
> >
> >
> > > Makes sense. Fedora is one of the systems where Python doesn't
> > >
On Sat, 7 Oct 2017, Gary E. Miller via devel wrote:
> On Sat, 7 Oct 2017 12:15:27 -0700 (PDT)
> Fred Wright via devel wrote:
>
>
> > Makes sense. Fedora is one of the systems where Python doesn't
> > include a "local" directory in the sys.path setup by default.
>
> Of course, no system following
Yo Fred!
On Sat, 7 Oct 2017 12:15:27 -0700 (PDT)
Fred Wright via devel wrote:
> > Having a PYTHONPATH setup could be leftover from when ntpsec needed
> > it, or it could be setup because some other package needs it.
>
> Most likely the former, since reasonable packages don't require
> PYTHONP
On Sat, 7 Oct 2017, Hal Murray via devel wrote:
> If I have PYTHONPATH defined as /usr/local/lib/python2.7/site-packages
> Then the python libs get installed in /usr/local/lib/...
> If I unset PYTHONPATH, they get installed to /usr/lib/...
Doh! (on Eric's behalf) That would be an unfortunate pr
If I have PYTHONPATH defined as /usr/local/lib/python2.7/site-packages
Then the python libs get installed in /usr/local/lib/...
If I unset PYTHONPATH, they get installed to /usr/lib/...
Having a PYTHONPATH setup could be leftover from when ntpsec needed it, or it
could be setup because some othe
Daniele Nicolodi via devel :
> But you and your mates may be too smart to think there is may be
> something you can learn.
>
> And this is going to be my last contribution to this mailing list.
Whoa. I wasn't outright rejecting your idea for post-1.0; in my book,
"smart" implies being willing to
Yo Daniele!
On Sat, 7 Oct 2017 00:32:33 -0600
Daniele Nicolodi wrote:
> On 06/10/17 18:47, Gary E. Miller via devel wrote:
>
> >> Debian solves the problem of installing user components in the
> >> system path creating a dist-libraries along the site-libraries
> >> path in the python module f
On 06/10/17 18:47, Gary E. Miller via devel wrote:
>> Debian solves the problem of installing user components in the system
>> path creating a dist-libraries along the site-libraries path in the
>> python module folder.
>
> Uh, yeah. Pretty much universal. Except you left out the sort of
> deta
Yo Daniele!
On Fri, 6 Oct 2017 18:37:53 -0600
Daniele Nicolodi via devel wrote:
> The reason is that a python interpreter cannot assume that any other
> path, outside the one in which it has been installed belongs to him.
Uh, no. In fact, nothing outside of the base python 'belongs' to
the ins
On 06/10/17 17:43, Gary E. Miller via devel wrote:
> Yo Daniele!
>
> On Fri, 6 Oct 2017 16:57:13 -0600
> Daniele Nicolodi wrote:
>
What if I want to have 2.7.1 and 2.7.2, for example?
>>>
>>> Gentoo can easily do that as well. Pretty common on gentoo.
>>
>> How? It is clearly not possi
Yo Daniele!
On Fri, 6 Oct 2017 16:57:13 -0600
Daniele Nicolodi wrote:
> >> What if I want to have 2.7.1 and 2.7.2, for example?
> >
> > Gentoo can easily do that as well. Pretty common on gentoo.
>
> How? It is clearly not possible with the scheme you described before.
Not gonna worry ab
On 10/6/17 4:21 PM, Gary E. Miller wrote:
> Yo Daniele!
>
> On Fri, 6 Oct 2017 15:59:05 -0600
> Daniele Nicolodi wrote:
>
>> On 10/6/17 1:46 PM, Gary E. Miller via devel wrote:
>>> Yo Daniele!
>>>
>>> On Thu, 5 Oct 2017 23:39:51 -0600
>>> Daniele Nicolodi via devel wrote:
>>>
The reason
On Thu, 5 Oct 2017, Hal Murray wrote:
> >> Warnings are easily lost in the noise. So either create the
> >> directory or treat it as an error and bail.
>
> > There are two issues with just "creating the directory":
> > 1) There's no guarantee that Python will actually use it.
> > 2) Creating the
Yo Daniele!
On Thu, 5 Oct 2017 23:39:51 -0600
Daniele Nicolodi via devel wrote:
> The reason why Python does not
> include /usr/local folders in his search path by default is: what if
> you want to install an alternative Pythion _interpreter_ there?
Uh, no. Each interpreter makes it's own pat
On 05/10/17 22:51, Hal Murray via devel wrote:
>>> Warnings are easily lost in the noise. So either create the
>>> directory or treat it as an error and bail.
>
>> There are two issues with just "creating the directory":
>> 1) There's no guarantee that Python will actually use it.
>> 2) Creating
>> Warnings are easily lost in the noise. So either create the
>> directory or treat it as an error and bail.
> There are two issues with just "creating the directory":
> 1) There's no guarantee that Python will actually use it.
> 2) Creating the directory requires root, and it would be
> undesir
On 10/5/17 6:23 PM, Gary E. Miller via devel wrote:
> Yo Fred!
>
> On Thu, 5 Oct 2017 14:10:24 -0700 (PDT)
> Fred Wright via devel wrote:
>
>> Exists? In sys.path?Usable?
>> --- ---
>> No No Unknown
>> No
Yo Fred!
On Thu, 5 Oct 2017 14:10:24 -0700 (PDT)
Fred Wright via devel wrote:
> Exists? In sys.path?Usable?
> --- ---
> NoNo Unknown
> NoYes Yes, but this can't happen (*)
> Y
On Sun, 1 Oct 2017, Eric S. Raymond wrote:
> Fred Wright via devel :
> > On Sun, 1 Oct 2017, Eric S. Raymond via devel wrote:
> > > Gary E. Miller via devel :
> > > > How do you plan that a local NTPsec install from source does not
> > > > overwite an NTPsec install from the native OS repositories
Hal Murray :
> >> Do we need a way to check that we are using the right library?
>
> >> I think that means we need the version string or time stamp in both the
> >> library and the code that uses the library with a simple sanity check at
> the
> >> top of the uses code.
>
> > It's not normal pr
>> Do we need a way to check that we are using the right library?
>> I think that means we need the version string or time stamp in both the
>> library and the code that uses the library with a simple sanity check at
the
>> top of the uses code.
> It's not normal practice to do this in Python.
Hal Murray :
>
> > There are two cases. User-installed code and binaries are supposed to go
> > under /usr/local/X; stuff from packages goes under /usr/X, where X = {bin,
> > lib}.
>
> I think that means our normal devel-mode install is "user-installed code".
Correct.
> I think that needs t
> There are two cases. User-installed code and binaries are supposed to go
> under /usr/local/X; stuff from packages goes under /usr/X, where X = {bin,
> lib}.
I think that means our normal devel-mode install is "user-installed code".
I think that needs to go in our documentation. (along wit
> I would bet that /usr/local//lib/python-X.Y is NOT in the sys.path no matter
> what.
So are we back to PYTHONPATH?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
On 01/10/17 22:28, Eric S. Raymond wrote:
> Daniele Nicolodi via devel :
>> Hello,
>>
>> I may be suggesting the obvious, but has anyone contacted the folks on
>> the Python Distutils mailing list
>> https://www.python.org/community/sigs/current/distutils-sig/ for their
>> advise? I'm surprised NT
Yo Fred!
On Sun, 1 Oct 2017 19:32:06 -0700 (PDT)
Fred Wright via devel wrote:
> On Sun, 1 Oct 2017, Eric S. Raymond via devel wrote:
>
> > Gary E. Miller via devel :
> > > How do you plan that a local NTPsec install from source does not
> > > overwite an NTPsec install from the native OS repo
> As usual, I thing adding an option is a bad substitute for figuring out what
> the right thing is and doing it.
Then create the directory.
> It would be easy enough to throw a warning if the desired /usr/local
> directory doesn't exist.
Warnings are easily lost in the noise. So either creat
Daniele Nicolodi via devel :
> Hello,
>
> I may be suggesting the obvious, but has anyone contacted the folks on
> the Python Distutils mailing list
> https://www.python.org/community/sigs/current/distutils-sig/ for their
> advise? I'm surprised NTPSec it the first project facing those problems.
Hal Murray :
> >>> I'll add language to INSTALL that one should make sure this directory
> exists
> >>> so as not to step on any distribution copy of the ntp library.
> >> That doesn't sound strong enough. It's too easy to accidentally screw up.
>
> > What would your recommend instead?
>
> I'
Hal Murray :
>
> > On most systems this will do the right thing.
>
> Which systems don't work right and/or what are we supposed to do there?
Under my Ubuntu system, /usr/local/lib/python-X.Y already exists. Under
some others, including Genooo, it doesn't. In the latter case, this
directory nee
Hello,
I may be suggesting the obvious, but has anyone contacted the folks on
the Python Distutils mailing list
https://www.python.org/community/sigs/current/distutils-sig/ for their
advise? I'm surprised NTPSec it the first project facing those problems.
Cheers,
Daniele
>>> I'll add language to INSTALL that one should make sure this directory
exists
>>> so as not to step on any distribution copy of the ntp library.
>> That doesn't sound strong enough. It's too easy to accidentally screw up.
> What would your recommend instead?
I'm not sure. This whole mess
Hal Murray :
>
> > I'll add language to INSTALL that one should make sure this directory exists
> > so as not to step on any distribution copy of the ntp library.
>
> That doesn't sound strong enough. It's too easy to accidentally screw up.
What would your recommend instead?
--
Fred Wright via devel :
>
> On Sun, 1 Oct 2017, Eric S. Raymond via devel wrote:
>
> > Gary E. Miller via devel :
> > > How do you plan that a local NTPsec install from source does not
> > > overwite an NTPsec install from the native OS repositories?
> >
> > That now will never happen if the /usr
> On most systems this will do the right thing.
Which systems don't work right and/or what are we supposed to do there?
> I have implemented and tested this solution, along with full documentation
> and packaging guidance.
I think the documentation needs more work in this area. A separate fil
On Sun, 1 Oct 2017, Eric S. Raymond via devel wrote:
> Gary E. Miller via devel :
> > How do you plan that a local NTPsec install from source does not
> > overwite an NTPsec install from the native OS repositories?
>
> That now will never happen if the /usr/local/lb/python-X.Y directory exists;
>
> I'll add language to INSTALL that one should make sure this directory exists
> so as not to step on any distribution copy of the ntp library.
That doesn't sound strong enough. It's too easy to accidentally screw up.
--
These are my opinions. I hate spam.
___
Gary E. Miller via devel :
> How do you plan that a local NTPsec install from source does not
> overwite an NTPsec install from the native OS repositories?
That now will never happen if the /usr/local/lb/python-X.Y directory exists;
the install logic will notice that.
I'll add language to INSTALL
Yo Eric!
On Sun, 1 Oct 2017 15:46:46 -0400 (EDT)
"Eric S. Raymond via devel" wrote:
> However there is good news for Gary and anybody else who is really
> worried about FHS compilance. While we cannot *guarantee* being able
> to do that, it was trivial to change the installation code so that i
I've spent the last several days researching all the various proposals
for how we handle locating the Python libraries, and trying to fully implement
several of them.
My conclusion is that Mark called this one right on the 28th:
>My inclination is to keep [Fred's] patch, document the lack of FHS
41 matches
Mail list logo
