This page is part of the web mail archives of SRFI 103 from before July 7th, 2015. The new archives for SRFI 103 contain all messages, not just those from before July 7th, 2015.
On Fri, 2009-09-25 at 09:56 -1000, Shiro Kawai wrote: > From: Derick Eddington <derick.eddington@xxxxxxxxx> > Subject: Re: Please drop the ^main^ thing > Date: Fri, 25 Sep 2009 11:23:22 -0700 > > > It's not only for single-component library names. If you have libraries > > (acme foo), (acme foo helper1), and (acme foo helper2), you may want > > them all organized under "acme/foo". > [...] > > A collection of libraries with common prefix (acme ---) might have an > > (acme) library and you may want all the libraries organized under > > "acme". I don't know how usual this will be. > > > > I've been under the impression there's enough demand for the > > organize-under-the-same-directory ability of the implicit file name to > > justify supporting it. I could be wrong. Am I? > > Just as a data point, I don't have desire to organize a library > under a single directory. I don't mind the library tarball > expands into acme/foo.sls, acme/foo/helper1.sls, acme/foo/helper2.sls... How do you feel about "littering" the top of a search path directory with acme.sls, etc., for single-symbol-named libraries? (I'm asking just to know your opinion.) (I think there will be enough single-symbol-named libraries that it will happen without support for an implicit file name.) > > Being able to organize all libraries with a shared name prefix under the > > same directory seems desirable so that, when managing the related > > libraries, the directory is the single thing for them, instead of having > > to remember there's also the file outside the directory and also deal > > with it. E.g., a collection with (acme) library is distributed in a > > tar/zip with files all under the "acme" directory, and when you want to > > move/delete it you only need to remember and deal with the directory. > > That sounds plausible, but most of the time I go for > some kind of install process, for libraries may need > some sort of setup depending on the environment. Some > libraries needs to install other components anyway > (e.g. auxiliary helper command). Then it is safer > to rely on 'uninstall' make target. > > Simple libraries may not need that, but it is a burden > to remember which ones need to be explicitly uninstalled > and which ones are just ok to remove single directory. > Since not all libraries are that simple, each library > needs to provide uninstall instruction anyways; I won't > rely on my memory and just remove one directory. While I do like automated management for library collections, and I look forward to having more automated management, I also think it's important to support collections which can simply be manually dropped into a search path and be immediately ready and which can be effectively manually managed, and that it's important to not marginalize this by saying everyone should use automated management. (I know you weren't saying that and were just giving your personal opinion, which I appreciate.) I think the organize-under-the-same-directory ability of the implicit file name is helpful for people who are frequently listing and manually managing the directories of search paths and collections to be able to see "acme" or "acme/foo" directory and know it's the entirety of everything in the library (sub-)collection. It makes the concept of "(sub-)collection" correspond to (sub-)directory, and the purpose of directories is to enable collections of things, and paths are just a consequence. -- : Derick ----------------------------------------------------------------