Re: fndir introspection, site-packages documentation

Re: fndir introspection, site-packages documentation

[Roman Neuhauser]

# schaefer@brasslantern.com / 2015-03-15 12:14:47 -0700:
> This really doesn't belong on zsh-users any more, in fact it probaby should
> have started out on zsh-workers to begin with.  I haven't changed the list
> target yet for this reply, but I suggest follow-ups go there.

but then i'm bound to miss replies.  i don't want to subscribe to
zsh-workers (yet)...

> Aside:  I don't suppose there's any point in again begging people to stop
> attaching patches as "text/x-patch" or "text/x-diff" or other silly MIME
> types that half my email clients [...]

i recon it'd be easier to reconfigure both halves of your email clients. :)
but, sorry to make your life difficult, it wasn't deliberate.

> On Mar 15,  3:14am, Roman Neuhauser wrote:
> }   ./Src/zsh -fc 'print -l "$ZSH_SITEFNDIR"'     
> }   /omg/share/zsh/site-functions
> 
> I don't have any strong objection to this although it seems like putting
> this value into every shell is overkill for the specialized purpose to
> which you propose to use it.  Can anyone give me a situation in which an
> oridinary user (i.e., not a software packager) would need this?

how about: a site admin wants to install a function for all users.

> Your doc change mentions
> 
> +tt(/usr/local/share/zsh/site-functions) is always included,
> +even if it does not exist, and cannot be configured away.
> 
> That's not quite correct: --disable-site-fndir turns it off, leaving
> only $prefix/share/zsh/$ZSH_VERSION/functions (or subdirs).

i described what i saw in testing.  what i haven't noticed is that
--prefix=/usr/local is a special case.  in fact, removing the hardcoded
failsafe neuters the purpose of the whole thing; you may treat this as a
bug report.

try it yourself:

  % ./configure --prefix=/omg --disable-site-fndir &&
    make &&
    ./Src/zsh -fc 'print -l $fpath'
  /usr/local/share/zsh/site-functions
  /omg/share/zsh/5.0.7-dev-1/functions

  % ./configure --disable-site-fndir &&
    make &&
    ./Src/zsh -fc 'print -l $fpath'
  /usr/local/share/zsh/5.0.7-dev-1/functions

the behavior with non-default --prefix is described in NEWS:

- The default $fpath/$FPATH is now designed always to include
  /usr/local/share/zsh/site-functions.  This directory does not need to
  exist.  Sites that set an explicit site directory can put that in
  /etc/zshenv as before.  The intention of the new path element is to
  increase the likelihood that locally added functions can be found with
  the shell running "out of the box", no matter how the shell was
  configured.

the behavior with *default* --prefix is, well, completely contrary to
the intent described: "no matter how the shell was configured" is blatantly
false thanks to this special case.

> Maybe the right thing is to throw all of this into a module (and doc
> for that module) that can be loaded by package maintainers to provide
> access to zsh's configure settings, but which other users can ignore.
> The more I think about it the more I like that idea.

zmodload or pkg-config?

-- 
roman

Re: fndir introspection, site-packages documentation

[Bart Schaefer]

On Mar 16,  9:08am, Roman Neuhauser wrote:
}
} but then i'm bound to miss replies.  i don't want to subscribe to
} zsh-workers (yet)...

We're pretty good about Cc'ing people when they ask to be.

Everybody, please Cc Roman.

} > Can anyone give me a situation in which an
} > oridinary user (i.e., not a software packager) would need this?
} 
} how about: a site admin wants to install a function for all users.

And the site admin can't determine where to do this by simply looking
at the value of $fpath?  If he's automating it for a bunch of dissimilar
platforms he's back to being a software packager.

} the behavior with *default* --prefix is, well, completely contrary
} to the intent described: "no matter how the shell was configured" is
} blatantly false thanks to this special case.

I'm leaving this to PWS as he made the changes to configure.ac.  I will
however note that I think --disable-site-fndir ought to do exactly that,
and the documentation blurb is what needs fixing.  If the shell is being
configured for some kind of secure/embedded environment, removing all
access to locally added functions is perfectly reasonable.

} > Maybe the right thing is to throw all of this into a module (and doc
} > for that module) that can be loaded by package maintainers
} 
} zmodload or pkg-config?

I meant a zmodload module.

Re: fndir introspection, site-packages documentation

[Ray Andrews]

On 03/16/2015 09:08 AM, Bart Schaefer wrote:
> We're pretty good about Cc'ing people when they ask to be.
>
>
Speaking of which ... can't the double post thing be cured?  It's not 
much trouble
to delete the 'workers' 'users' doubles, but I'd have thought that there 
might be
some way of handling that internally.   Sometimes one gets three copies 
of things.

Re: fndir introspection, site-packages documentation

[Bart Schaefer]

On Mar 16,  9:46am, Ray Andrews wrote:
}
} Speaking of which ... can't the double post thing be cured?

Don't subscribe to both lists.  If you want everything, subscribe only
to -workers, it gets copied on everything sent to -users.  If you want
to avoid the deep code discussions, subscribe only to -users.

Re: fndir introspection, site-packages documentation

[Ray Andrews]

On 03/17/2015 08:41 AM, Bart Schaefer wrote:
> On Mar 16,  9:46am, Ray Andrews wrote:
> }
> } Speaking of which ... can't the double post thing be cured?
>
> Don't subscribe to both lists.  If you want everything, subscribe only
> to -workers, it gets copied on everything sent to -users.  If you want
> to avoid the deep code discussions, subscribe only to -users.
>
Yeah I know. But I thought since it's the same server, something might be
done to automate removing the duplicates. I want to see what's going on @
workers but not unsubscribe from users either in case I do unsubscribe
from workers--since I have little to contribute and understand almost 
nothing
and probably never will. It's not worth any trouble tho.

Re: fndir introspection, site-packages documentation

[Roman Neuhauser]

# schaefer@brasslantern.com / 2015-03-16 09:08:29 -0700:
> On Mar 16,  9:08am, Roman Neuhauser wrote:
> }
> } but then i'm bound to miss replies.  i don't want to subscribe to
> } zsh-workers (yet)...
> 
> We're pretty good about Cc'ing people when they ask to be.
> 
> Everybody, please Cc Roman.

well, i've subscribed to workers@ so, no need for cc's anymore.
 
> } the behavior with *default* --prefix is, well, completely contrary
> } to the intent described: "no matter how the shell was configured" is
> } blatantly false thanks to this special case.
> 
> I'm leaving this to PWS as he made the changes to configure.ac.  I will
> however note that I think --disable-site-fndir ought to do exactly that,
> and the documentation blurb is what needs fixing.  If the shell is being
> configured for some kind of secure/embedded environment, removing all
> access to locally added functions is perfectly reasonable.

i don't have an opinion on which way it should be, but it needs to be
consistent.
 
> } > Maybe the right thing is to throw all of this into a module (and doc
> } > for that module) that can be loaded by package maintainers
> } 
> } zmodload or pkg-config?
> 
> I meant a zmodload module.

i know, i was hinting at the fact that a .pc file would suffice, maybe
you'd find it "good enough".  and there's the added benefit of it being
the standard interface for this kind of things...

-- 
roman

Re: fndir introspection, site-packages documentation

[Bart Schaefer]

On Mar 16,  6:05pm, Roman Neuhauser wrote:
}
} i know, i was hinting at the fact that a .pc file would suffice, maybe
} you'd find it "good enough".  and there's the added benefit of it being
} the standard interface for this kind of things...

It's not the standard interface on all OS's / distributions.

Re: fndir introspection, site-packages documentation

[Roman Neuhauser]

# schaefer@brasslantern.com / 2015-03-17 08:45:05 -0700:
> On Mar 16,  6:05pm, Roman Neuhauser wrote:
> }
> } i know, i was hinting at the fact that a .pc file would suffice, maybe
> } you'd find it "good enough".  and there's the added benefit of it being
> } the standard interface for this kind of things...
> 
> It's not the standard interface on all OS's / distributions.

ok then, i'll give it a whirl.

-- 
roman

Re: fndir introspection, site-packages documentation

[Peter Stephenson]

On Mon, 16 Mar 2015 09:08:29 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> I will
> however note that I think --disable-site-fndir ought to do exactly that,
> and the documentation blurb is what needs fixing.  If the shell is being
> configured for some kind of secure/embedded environment, removing all
> access to locally added functions is perfectly reasonable.

Yes, that seems right.

diff --git a/NEWS b/NEWS
index bf8969b..5b776ba 100644
--- a/NEWS
+++ b/NEWS
@@ -30,8 +30,9 @@ Changes since 5.0.0
   exist.  Sites that set an explicit site directory can put that in
   /etc/zshenv as before.  The intention of the new path element is to
   increase the likelihood that locally added functions can be found with
-  the shell running "out of the box", no matter how the shell was
-  configured.
+  the shell running "out of the box", unless the shell has been
+  deliberately configured differently by the installer for some special
+  purpose.
 
 - Individual pattern characters can be disabled.  For example, to allow '^'
   to be an ordinary character even if the option EXTENDED_GLOB is set, use

Re: fndir introspection, site-packages documentation

[Roman Neuhauser]

# p.stephenson@samsung.com / 2015-03-16 17:13:12 +0000:
> diff --git a/NEWS b/NEWS
> index bf8969b..5b776ba 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -30,8 +30,9 @@ Changes since 5.0.0
>    exist.  Sites that set an explicit site directory can put that in
>    /etc/zshenv as before.  The intention of the new path element is to
>    increase the likelihood that locally added functions can be found with
> -  the shell running "out of the box", no matter how the shell was
> -  configured.
> +  the shell running "out of the box", unless the shell has been
> +  deliberately configured differently by the installer for some special
> +  purpose.

1. run

  ./configure --prefix=/wtf --disable-site-fndir

2. explain continuing presence of "/usr/local/share/zsh/site-functions".

btw, you've just turned the last sentence into a perfect contradiction
of the paragraph it is closing.  the first stentence still reads:
"The default $fpath/$FPATH is now designed always to include [...]"

again: [...] designed to *always* [...].

emphasis mine.  which is it?  always, or unless/provided-that?

NEWS with your change, "always" and "unless" contradicting each other:

- The default $fpath/$FPATH is now designed always to include
  /usr/local/share/zsh/site-functions.  [...]
  The intention of the new path element is to
  increase the likelihood that locally added functions can be found with
  the shell running "out of the box", unless the shell has been
  deliberately configured differently by the installer for some special
  purpose.

-- 
roman

Re: fndir introspection, site-packages documentation

[Bart Schaefer]

On Mar 16,  5:13pm, Peter Stephenson wrote:
} Subject: Re: fndir introspection, site-packages documentation
}
} On Mon, 16 Mar 2015 09:08:29 -0700
} Bart Schaefer <schaefer@brasslantern.com> wrote:
} > I will
} > however note that I think --disable-site-fndir ought to do exactly that,
} > and the documentation blurb is what needs fixing.  If the shell is being
} > configured for some kind of secure/embedded environment, removing all
} > access to locally added functions is perfectly reasonable.
} 
} Yes, that seems right.

OK, but that's not actually what happens if you change the --prefix.  You
can't currently get both a different prefix and no extra directory in fpath.

Re: fndir introspection, site-packages documentation

[Peter Stephenson]

On Tue, 17 Mar 2015 08:52:33 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Mar 16,  5:13pm, Peter Stephenson wrote:
> } Subject: Re: fndir introspection, site-packages documentation
> }
> } On Mon, 16 Mar 2015 09:08:29 -0700
> } Bart Schaefer <schaefer@brasslantern.com> wrote:
> } > I will
> } > however note that I think --disable-site-fndir ought to do exactly that,
> } > and the documentation blurb is what needs fixing.  If the shell is being
> } > configured for some kind of secure/embedded environment, removing all
> } > access to locally added functions is perfectly reasonable.
> } 
> } Yes, that seems right.
> 
> OK, but that's not actually what happens if you change the --prefix.  You
> can't currently get both a different prefix and no extra directory in fpath.

I think you're suggesting the following.  Let we know explicitly how
this needs to change if not.

pws

diff --git a/configure.ac b/configure.ac
index 7e770cd..e4de193 100644
--- a/configure.ac
+++ b/configure.ac
@@ -318,7 +318,8 @@ fi], [sitefndir=${datadir}/${tzsh_name}/site-functions])
 dnl Add /usr/local/share/zsh/site-functions if not yet present
 dnl owing to $sitefndir, whether or not explicitly given.
 dnl If not explicitly given, it hasn't been expanded yet.
-if test X$sitefndir = X/usr/local/share/zsh/site-functions
+if test X$sitefndir = X/usr/local/share/zsh/site-functions || \
+   test X$sitefndir = Xno
 then fixed_sitefndir=''
 elif test X$prefix != X/usr/local; then
   if test X$prefix = XNONE && test X$ac_default_prefix = X/usr/local; then

Re: fndir introspection, site-packages documentation

[Bart Schaefer]

On Mar 17,  6:46pm, Peter Stephenson wrote:
}
} I think you're suggesting the following.  Let we know explicitly how
} this needs to change if not.
} 
} +if test X$sitefndir = X/usr/local/share/zsh/site-functions || \
} +   test X$sitefndir = Xno

That looks like it will do what I was suggesting, yes.