Given the marginal role played by the SQL I would go with the two-asd approach, with the default install using the non-sql version and a bit of documentation on how to build the other for thems that are keen on it.

Or go crazy and hit the ASDF support for how to do it magically (it is designed for smart loading) but then it seems you still need to document for users why they end up without the SQL bit if they do not have the dependencies in place.

hth, kt

-kt

On Wed, Apr 6, 2016 at 7:21 PM, Don Morrison dfm2@cmu.edu wrote:

I'm tidying up a library of code, Roan (for building things that play with change ringing, you probably don't want to know the details :-), for eventual inclusion in Quicklisp. In thinking about its dependencies I've run into an issue I'm not sure how best to address. I asked Zach Beane for advice, but he, too, isn't sure how best to deal with it, and suggested I consult folks on this list.

My library has dependencies upon several others, all readily available from Quicklisp. One them, though, cl-sqlite (or perhaps it's better referred to as sqlite, it's rather conflicted about what it wants to call itself) in turn has a dependency on a binary library, sqlite3. For example, if the sqlite3 binary library is not install, doing

(ql:quickload :sqlite)

signals an error when it's setting up FFI things.

However Roan's use of SQLite is not essential to Roan's usefulness (well, it's probably not all that useful to most people anyway, only to those interested in change ringing, a small audience). There's really only one, tiny corner of functionality in Roan it supports. While sqlite3 is easily obtained, it would seem polite to allow use of Roan without it, simply disabling the two functions that depend upon it. The "disable if the cl-sqlite stuff is not present" part I can easily do. What's causing me to scratch my head is figuring out how to set things up so Roan will still install whether or not the sqlite3 binary library is present.

Three unattractive possibilities that come to mind are

• Define two different roan ASDF systems: one consisting of most stuff,

without the SQLite-dependent bits, and the other the "real" one that loads the first plus cl-sqlite. Then the user picks which one to load based on need.

• Define something to push onto *features* that, if present, comments out

in roan.asd the dependency on cl-sqlite, etc. Then the user has to push the appropriate keyword onto *features* before loading roan, if she doesn't have sqlite3.

• I'm guessing I could probably include some code in the roan.asd file

that does something or other nasty looking for the binary library, and then adjusts the defsystem appropriately or something (ugh).

None of these is particularly appealing. The first two seem to put too much on the shoulders of the poor luser who just wants to load the darn thing without having to think about lower level stuff, and the last (a) seems to confound too much actually doing complex, kludgy stuff with what should be just declarative, and (b) is something I seriously doubt I'd get right, especially in a portable way.

It seems there has got to be A Better Way. Has anyone dealt with a similar situation? Or, even if not, might you have a good idea?

I suppose an attractive possibility might be to wrap some sort of condition handler around the place inside ASDF that's trying to load the cl-sqlite dependency, but I don't know my way around the ASDF internals enough to have a sense of where that should be done, or if it's even practical. Is there a good place inside of ASDF to do such a thing? It seems fairly modular, so it seems likely. Maybe it's as easy as defining a specialized method of some sort, or an :around method on something or other?

Thanks!

-- Don Morrison dfm2@cmu.edu "There were two cultures, as far as he was concerned. One was the real one, the other was occupied by people who liked machinery and ate pizza at unreasonable hours." -- Terry Pratchett, _The Last Hero_

This reply has nothing to do with the question, but you may be interested to learn that there is a useful entry for Change Ringing in the Harvard Dictionary of Music, which ends "Change ringing is still widely practiced in England." I'm paraphrasing from memory 40 years ago, but the 1st edition of the Dictionary (hard to find) added "It is a typical English recreation providing healthful physical exercise coupled with some simple intellectual effort." This last sentence disappeared in the 2nd ed.

Thought you'd want to know all this while pondering ASDF.

On Wed, Apr 6, 2016 at 4:21 PM, Don Morrison dfm2@cmu.edu wrote:

I'm tidying up a library of code, Roan (for building things that play with change ringing, you probably don't want to know the details :-), for eventual inclusion in Quicklisp. In thinking about its dependencies I've run into an issue I'm not sure how best to address. I asked Zach Beane for advice, but he, too, isn't sure how best to deal with it, and suggested I consult folks on this list.

My library has dependencies upon several others, all readily available from Quicklisp. One them, though, cl-sqlite (or perhaps it's better referred to as sqlite, it's rather conflicted about what it wants to call itself) in turn has a dependency on a binary library, sqlite3. For example, if the sqlite3 binary library is not install, doing

(ql:quickload :sqlite)

signals an error when it's setting up FFI things.

However Roan's use of SQLite is not essential to Roan's usefulness (well, it's probably not all that useful to most people anyway, only to those interested in change ringing, a small audience). There's really only one, tiny corner of functionality in Roan it supports. While sqlite3 is easily obtained, it would seem polite to allow use of Roan without it, simply disabling the two functions that depend upon it. The "disable if the cl-sqlite stuff is not present" part I can easily do. What's causing me to scratch my head is figuring out how to set things up so Roan will still install whether or not the sqlite3 binary library is present.

Three unattractive possibilities that come to mind are

• Define two different roan ASDF systems: one consisting of most stuff,

without the SQLite-dependent bits, and the other the "real" one that loads the first plus cl-sqlite. Then the user picks which one to load based on need.

• Define something to push onto *features* that, if present, comments out

in roan.asd the dependency on cl-sqlite, etc. Then the user has to push the appropriate keyword onto *features* before loading roan, if she doesn't have sqlite3.

• I'm guessing I could probably include some code in the roan.asd file

that does something or other nasty looking for the binary library, and then adjusts the defsystem appropriately or something (ugh).

None of these is particularly appealing. The first two seem to put too much on the shoulders of the poor luser who just wants to load the darn thing without having to think about lower level stuff, and the last (a) seems to confound too much actually doing complex, kludgy stuff with what should be just declarative, and (b) is something I seriously doubt I'd get right, especially in a portable way.

It seems there has got to be A Better Way. Has anyone dealt with a similar situation? Or, even if not, might you have a good idea?

I suppose an attractive possibility might be to wrap some sort of condition handler around the place inside ASDF that's trying to load the cl-sqlite dependency, but I don't know my way around the ASDF internals enough to have a sense of where that should be done, or if it's even practical. Is there a good place inside of ASDF to do such a thing? It seems fairly modular, so it seems likely. Maybe it's as easy as defining a specialized method of some sort, or an :around method on something or other?

Thanks!

-- Don Morrison dfm2@cmu.edu "There were two cultures, as far as he was concerned. One was the real one, the other was occupied by people who liked machinery and ate pizza at unreasonable hours." -- Terry Pratchett, _The Last Hero_

​On Wed, Apr 6, 2016 at 7:21 PM, Don Morrison dfm2@cmu.edu wrote:

I suppose an attractive possibility might be to wrap some sort of condition handler around the place inside ASDF that's trying to load the cl-sqlite dependency, but I don't know my way around the ASDF internals enough to have a sense of where that should be done, or if it's even practical. Is there a good place inside of ASDF to do such a thing? It seems fairly modular, so it seems likely. Maybe it's as easy as defining a specialized method of some sort, or an :around method on something or other?

Ah, I now see that something like this is unlikely to be practical: am I correct in believing folks are likely to be operating with widely disparate versions of ASDF?

It is beginning to appear that the most practical solution today, or at least the one least likely to cause further problems, is two different systems. ​​

Dear Don,

sorry for a late reply.

The intended way to use ASDF in your case would be to use two or more systems, that may be defined in the same .asd file (using the / syntax to name a secondary system: roan, roan/core, roan/sqlite, etc.) or separate .asd files (using - or . as a separator).

This way, you can unambigously name what is or isn't loaded in a given system in a way that doesn't depend on configuration.

For a system that goes to lengths at doing the right thing with respect to ASDF yet does some automatic configuration detection, try net.didierverna.clon. It has ...clon.core and ...clon.termio systems, and a special ...clone.setup/termio for autodetection.

I recommend strongly against using user-specified *features* to control what does or doesn't go into a system (as opposed to system-provided or system-deduced features).

Also, regarding people using disparate versions of ASDF: if you can always ship with the latest ASDF version and depend on its features. Also, implementations released in the last two years include ASDF 3.1.2 or later (which unhappily doesn't include clisp).

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If you think health care is expensive now, wait until you see what it costs when it's free. — P.J. O'Rourke