#+:swank is not good for conditional dependency

[attila-lendvai]

compile the lib with swank loaded -> a .fasl that depends on swank. now restart your lisp without swank, try to load the library -> error, swank package missing.

the proper way to resolve this is to record a trivial-features/swank asdf system that explicitly depends on swank, and then let users chose what they want. or just let them depend on swank and use the swank internals.

[Shinmera]

Nah.

The proper way to do this is to resolve the availability of Swank at load-time rather than at compile-time.

[attila-lendvai]

that just moves the error to runtime, and i see no reason how that's any more useful. but anyways, i don't have a skin in this game, so... i just wrote up the situation to have it recorded.

[Shinmera]

It is much more useful because usually you use a library in one of two situations:

1. independently
2. in a development environment

In the first you probably won't have slime around, and in the second you already will before you load it. This gets rid of most of the confusion that compile-time constants introduce. The two systems is a bad idea since it would basically require you to change your dependencies in your software depending on which environment you load it in.

[Shinmera]

Alternatively I could remove the slime clause altogether, since it's only really used as preemptive future-proofing and is not strictly needed at all.

[attila-lendvai]

but is there a use-case where argv parsing is optional, decided at runtime?

if not, then i'd expect compile time errors and explicit dependencies, either through one or multiple ASDF systems.

[Shinmera]

Huh? Argv parsing? This library is for fetching the lambda-list of common lisp functions.

[attila-lendvai]

err, scratch that then... but my question applies equally in the lambda list context.

what we do in similar situations is that there are some integration systems (e.g. :hu.dwim.util/error-handling+swank) that are loaded by a custom develop-op ASDF operation that we use for loading stuff in our dev env's.

and if the dependency is needed for the proper functioning of the system (e.g. swank is needed for backtrace logging), then we just add the dependency explicitly to the system where it's needed.

at one point we used asdf-system-connections, but it was painfully wrong and wasted a lot of debugging time. then we briefly tried this kind of #+ but it very quickly led to rmfasl annoyance and wasted time by recompiling stuff... so we just decided for explicit dependencies and it's now predictable.

[Shinmera]

Ok. This isn't much of an argument, but I have to say that I've never before heard of anyone doing it that way.

What I do know for certain however, is that a lot of people use the same machine and setup to develop their application in Slime and then occasionally test it headless to see if it runs in "deployment mode". In that case stale FASLs are indeed a problem, but asking them to change their library ecosystem around to account for the non-dev case seems completely unreasonable to me. Instead, checking for the availability of Slime at load-time would solve the problem that they experience.

[attila-lendvai]

we've been there and it bit us enough times to learn that it's not worth it in the long term. but again, i don't have skin in this game, so...

or another wording of the general principle: reproducible builds are good, and thus moving towards it also.