[gambit-list] Libraries for day-to-day projects ?

mikel evins mevins at me.com
Tue Jul 8 13:02:46 EDT 2014


On Jul 8, 2014, at 11:38 AM, Álvaro Castro-Castilla <alvaro.castro.castilla at gmail.com> wrote:

[...snip...]

> 
>  
> - an easily-accessible repository for the libraries
> 
> I'm using github. Installation is done through cloning a repo and running a script.

Zach uses Github, too.

> - an efficient way to collect updates to the libraries and make them accessible from the repo
> 
> Not sure what you mean by this. I'm using github, and people who have contributed to SS have done it through git forking and pull requests.

Libraries go through various versions. You want it to be easy for your tools to fetch the latest versions of libraries, and to fetch specific versions of libraries when the user wants that.

Here's what a typical interaction with Quicklisp looks like; let's suppose I know I want to use a library called "fad". I start by searching to see if Quicklisp knows about it:


CL-USER> (ql:system-apropos "fad")
#<SYSTEM cl-fad / cl-fad-0.7.2 / quicklisp 2014-05-25>
#<SYSTEM cl-fad-test / cl-fad-0.7.2 / quicklisp 2014-05-25>

Notice that the metadata maintained by Quicklisp reports both the version that cl-fad assigns to itself, and also an independent version maintained by Quicklisp. That means that Quicklisp can tell the differences between versions independently of the version-naming convention of any particular library. However, it also means that Quicklisp has to do its own (minimal) packaging in order to wrap its version number around the library. That's not such a bad thing, as it turns out, since it also means that using Quicklisp to get a library means you can rely on getting a consistent version of it. 

> - a tool that enables you to quickly and easily search the libraries by name and description
> 
> That's a big TODO. I love this idea and I want to provide it. The first step is documenting everything, and that is a pretty big task.

You can do a lot even without documentation of the libraries. Many libraries in Quicklisp have sparse or even nonexistent documentation. I'm not saying that's good; what I am saying is that the apropos search is useful even if you only have library names.

> - a tool that enables you to quickly and easily download and install any given library
> 
> The tool is called SSpheres, and does this. Is not perfect, as many things being improved, but it works.
>  
> - an easy way to tell the tools about nonstandard and local repositories
> 
> This is important, and easy to add (although not available at the moment). I thought about it as a necessary functionality since the beginning.

Quicklisp enjoys a sort of shortcut here: it uses ASDF to load libraries, and you can tell Quicklisp about local libraries simply by adding pathnames to ASDF's registry of search paths. You mentiond that you have a library-loading tool; perhaps a similar arrangement would work for SchemeSpheres.

> - an easy way to tell the tools that you want a specific version of a library, or multiple versions of a library
> 
> Same here. I intend to implement versions with Git tags for this. At the moment "versioning" is just used for differentiating targets (such as "debug", "optimized", etc..)
> 
> Thank you for your interaction, I really appreciate.

Sure; if it makes it easier to build SchemeSpheres and make it great, I'm glad to help.




More information about the Gambit-list mailing list