Re: two sets of modules under /usr/local/lib/zsh ?

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

(Moved from zsh-workers to zsh-users, as most of the developers are likely
to know this already, but it may be of interest to users).

Quick recap:  In 3.1.6-pws-13, hierarchical module naming was introduced,
which means that when you install 3.1.9 you appear to have two of each of
the modules, one under .../zsh/3.1.9/ and one under .../zsh/3.1.9/zsh/.
The modules directly under .../zsh/3.1.9/ were eliminated in 3.1.9-dev-5,
so you won't see "two sets" any more when 4.0 is released.

This led to a question about how one is supposed to load the modules.

On Sep 9,  3:44pm, Will Day wrote:
}
} Well, in my case, I had MODULE_PATH already being set in my startup files,
} and so I just added the 'zsh' subdir to the path.  Of course, reading your
} subsequent mail, this is apparently the wrong thing to do.

Yes, that's the wrong thing to do.  The "alias modules" are just dummy
files that load nothing, used to cause a dependency on the real modules
in the zsh/ subdirectory.  So in 3.1.7 through 3.1.9, when you say (with
the default MODULE_PATH) `zmodload stat' you end up loading two modules,
`zsh/stat' which is the one you really want, plus the dummy `stat' module
that depends upon zsh/stat.

The "real" modules all have dependency information expressed as the
hierarchical name (e.g. zsh/compctl depends on zsh/complete), so if you
load by the base name with a modified MODULE_PATH, zsh will not do the
right thing with the dependencies.  (For zsh-users:  The "subsequent
mail" mentioned above suggests that we try to do something about this.)

} Also, I'm not quite clear on why the MODULE_PATH isn't to be used like a
} shell PATH, listing all the directories wherein modules may be found.

Well ... that *is* how it's used, really ... there's nothing that says
you *can't* have a module at the top of the hierarchy (like the alias
modules are).  But when the (separate) decision to have hierarchically-
named modules was made, the implementation chosen was to reflect the
hierarchical name of the module as actual filesystem hierarchy, which
meant it had to be *relative* to the directories in the MODULE_PATH.

The thing about both PATH and MODULE_PATH is that they imply an ordering
-- if identically-named commands or modules appear in two places, only the
first one found is used -- which the hierarchical naming scheme does not;
that is, you're *supposed* to be able to have both a local/files and a
zsh/files module, and use either of them (or both if they don't supply
conflicting functionality).

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net