Am Freitag, den 31.01.2020, 18:38 +0100 schrieb David Kastrup: > Urs Liska <m...@ursliska.de> writes: > > > Am Mittwoch, den 29.01.2020, 07:01 -0800 schrieb d...@gnu.org: > > > On 2020/01/29 12:20:10, mail5 wrote: > > > > Unfortunately I haven't set up a build system on my new > > > > computer > > > > yet, > > > so this > > > > patch is not tested locally at all, so I'm humbly waiting for > > > > the > > > automated > > > > tests to succeed or fail ... > > > > > > I don't like the "use-modules clauses adjusted accordingly". I > > > don't > > > think it makes sense readjusting use-modules clauses all the time > > > while > > > we are deciding on the final module organisation, so I'd strongly > > > suggest first biting the bullet and deciding on a syntax for a > > > user-level command able to load Scheme modules without further > > > options, > > > and then introduce that command. In that manner, future > > > directory > > > organisations (which are almost certain to come) will not affect > > > the > > > source of user-level documents any more. > > > > > > https://codereview.appspot.com/567140045/ > > > > Maybe I'm missing something, but AFAICS there will always be the > > need > > for a module path like (ice-9 regex), or (scm display-lily). We > > will > > have that with *any* user-facing load syntax. > > \loadScmPackage display-lily > > or even > > \loadPackage display-lily.scm > > with the last .scm getting interpreted specially. > > #(use-modules ...) is not a user-facing load syntax. We don't want > people to have to change their input when an optional package > migrates > to the system or a local package changes hierarchy. Specific path > components may make sense for disambiguation, but if I take a look at > what LaTeX does, a flat hierarchy as first user-level approximation > does > not appear to have significant scaling problems.
I'm not so sure about that. In the LaTeX world this means that you have to come up with file names that are unique to the whole ecosystem because otherwise you're relying on luck that "your" file is found first in case of conflicts. I had this several times, mostly in the form of requests of TeX Live maintainers to rename files which were considered dangerously generic. The other thing to consider is that path components are (currently) not only used for disambiguation but also for the lookup. LilyPond starts searching for files at each include path, and it relies on relative paths starting from a (any) include path. LaTeX, however, recursively searches for files starting from the include paths. I think going that route would have several negative impacts (disadvantage/risk): * The recursive search is potentially expensive * There are actual risks of loops in the search path * Targets are not really specified, using relative paths is more expressive and explicit. * kpathsea is pretty complex and has corner cases that don't work well (e.g. it doesn't always follow symlinks when a directory does not contain at least one "real" file), and we would knowingly have to decide creating and maintaining a comparable tool So, requiring explicit paths gives clearer interfaces (although more typing is required) and reduces searching complexity. In the case of display-lily and all other built-in modules we can reduce this by adding the scm directory to the include path. But for external packages I am pretty sure that using explicit paths from the include paths (like we already have it with \include) makes sense. ### However, I'd like to stress that we are (or at least should be) talking about several different things when saying "package" and "loading": 1) Loading a package/module *file*, parsing its code and making elements available to clients 1a) One question is how to address these includable files 1b) The other question is where the elements and which elements of the loaded files are visible. 2) Loading/using a package in a more conceptual sense, like "edition- engraver" or "scholarLY". Here all the stuff about option handling becomes (more) relevant, and the questions of 1) are prerequisites. ### So when talking about new commands to "load packages" we are actually talking about two different things that *both* have to be done. Urs