Re: Errors on module feature [auto]loading (Re: zsh 5.0.2-test-1 is available)

[Peter Stephenson <p.w.stephenson@ntlworld.com>]

On Sun, 10 Nov 2013 12:03:54 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> [> workers]
> 
> On Nov 9, 10:32pm, Peter Stephenson wrote:
> }
> } Suppose we load builtin bar from zsh/foo at some point, doesn't matter
> } how, then run "zmodload -a bar zsh/foo". We find that a builtin bar
> } exists. We can then check that zsh/foo is already loaded, and is
> } already providing builtin bar.
> 
> And conversely we can tell that a builtin bar already exists that is not
> provided by zsh/foo ?  This is the part that I thought for some reason
> was difficult.

We can tell a builtin is loaded easily enough --- this is the test
that's currently reporting the error if the builtin is already provided
by anything at all.  The new trick is that we then look to see if
zsh/foo is loaded already, and if so whether it's providing that
builtin, which we can do e.g. by querying the features.  (That's
probably the best way without straining the standard module interface, I
think.)  If this says that b:bar is present and enabled, we know that
zsh/foo is providing it, because zsh/foo wouldn't have said it was
enabled otherwise, it would have reported an error instead.  If it isn't
enabled as a feature from zsh/foo, then something else is providing the
builtin; we don't care what, this is an error.

This is generic to any sort of feature, so exactly the same applies to
the other types of feature.

> I'm OK with this given the precondition.  Do all the rules about warning
> on circular dependency, etc., apply?  If I try to explicitly autoload
> from zsh/foo a feature that would implicitly be provided by zsh/bar,
> when if ever would an error occur?

Hmm... I don't know how this works at the moment, but it's not really
relevant because zsh/bar won't show the builtin as a feature --- unless
a dependent module is providing a conflicting builtin, but that's a
configuration problem, not a user problem.  The method doesn't care
about dependencies, it cares that you specified the right module, which
I think is reasonable --- the documentation tells you.
 
> Aside:  Should we update the manual to say that the right way to test for
> module existence is "zmodload -F module" (with no feature arguments)?  This
> checks that the module could be loaded without enabling anything, whereas
> "zmodload [-i] module" enables all the default features.

It doesn't just test for it, it does in fact load it, but without
enabling any of the features.  If you didn't want anything in the module
at that point you'd need to unload it again, but the combined operation
should be free of side effects.  That might be worth mentioning.

pws