Shims for old systems

[73budden]

Hello! Thanks for the feedback. Actually I don't use lisp for about a
half a year now, and looking for a new job, so I definitely have no
time to dig into much detail. But I was keeping those shims in mind
for about a year, so I thought now it is a good time to share
thoughts. I'll try to clarify some of my points.

1. Overall ideology. Lisp community is shrinking. Keeping things
simple and sustainable is a key to survival. In asdf I see the
accumulation of complexity with no end. That is bad generally.

2. Shims. If the library is dead (unmaintained), there is no effort
maintaining shims once they are created, except if asdf 4 appear that
breaks compatibility. If anyone (alive) uses the lib, he anyways have
to deal with the broken system which does not build. By introducing
shims, we create a way to share and re-use this work. The key here is
that shim is alive (can be maintained, e.g. if asdf4 appear sometimes)
while the library is dead. Forking all libs is also the way to go, but
it has issues, at least in case of github. Fork must be independent
(have no reference to the previous work, but be loaded into github
independently), otherwise there is a mess. With no access to original
lib there is no way to say "this library is dead, and that fork is a
preference". Forks by themselves are not searchable. Entry point is
the original lib, not the fork. So while searching for any lib, one
has to study the fork network and guess which library is the right
one, which is heuristical and error-prone (there is no way to
distinguish someone's personal experiments from the mainstream fork).
If there is a lisp-specific index of mainstream forks, then of course
it can be maintained instead of shims. Quicklisp is an obvious place
for that. Maybe it is a better than shims (no need to change asdf),
but then github search is no more an entry point to find lisp libs.
Maybe it is fine, I didn't think about it.

Having a special key which disables warnings does not look as a good
decision, because it adds more complexity (not only in the
implementation, but also in the use of the asdf) and preserves the old
mess. So the goal to get rid of that misnamed systems is not achieved
at all.

3. Uprgrade. I know there are vendor-specific asdf versions, but it
does not matter. What we need from old asdf is its database converted
to the new format, no need to do hot upgrade. There is no problem to
specify two things in a config file - a path to a converted database,
saved as a file, and a path to a new asdf, so we don't need things
like old-asdf:load-system :new-asdf. Just don't use old asdf to load
new one, use simple "load", which will destroy old asdf package,
create a new one and load the database from the file. That's it. We
only need a converted for each old asdf version which exports the
database to the file. This way asdf code for old and new versions is
decoupled completely, and the upgrade process simplifies dramatically.
As far as I can imagine, asdf database structure is very simple. But
if the implementation contains a set of asdf files in an obsolete
format, then implementation can be broken after the upgrade, Current
approach does not solve this either: new asdf must understand old asdf
files also. Here again we come to the idea of shims for
implementation's asdf files, which can be stored externally if it is
impossible to promote changes to the implementation.

Sorry I have no resources to participate in the implementation, but if
I return to the lisp universe at some point, I'll maybe start with
something like this.

Best Regards!


2019-02-20 4:57 GMT+03:00, Attila Lendvai <attila at lendvai.name>:
>> The shims idea is interesting, but isn't it a lot of trouble to make and
>> maintain a shim (which has to somehow indicate where to find the source
>> files for the library), compared to forking a system?
>
> +1
>
> there's already the sharplispers group for taking over unmaintained
> systems (not to be confused with hostile systems):
>
> https://github.com/sharplispers
>
> --
> • attila lendvai
> • PGP: 963F 5D5F 45C7 DFCD 0A39
> --
> “Tact is a skill that can turn brutal honesty into just honesty. It's
> a skill that develops with practice, and one that's harder to use when
> emotions are running high. But you can't go towards someone with a
> verbal fist and expect a hug in return. When method matches intention,
> outcomes are much more peaceful.”
> — Doe Zantamata
>