Shims for old systems

[Robert Goldman]

On 19 Feb 2019, at 1:18, 73budden wrote:

> Hi!
>
> Every time I read "asdf", I feel a pain. I've read that there is an
> attempt to gain resources to improve asdf. I have a sort of plan.
>
> 1. Shims. Recent tightening of rules for system definitions is ok, but
> there are old systems with no maintainers. If such system does not
> obey the rules, one can introduce "shim" concept. I've met them in JS
> culture where they serve as third-party adapters to connect two
> mismatching things.
>
> In the simplest way shim is just an alternative directory hierarchy
> with shim asd files, isomorphic to local lisp directory structure.
>
> When looking for system, asdf must search in shims directory first,
> and only then in the directory of the file itself. Also things like
> quicklisp might take care of installing shims where they exist.
> Maintanence of shims for all popular systems can be done within a
> separate git repository.

For the moment, I think the only issue related to rules tightening is 
that we ask people to use the proper complex system names (see my recent 
change to the ASDF manual, available from the page on `common-lisp.net`. 
  Is that what you are referring to?  Or are there other issues causing 
pain?

If it's just that, insert the name of the asd file (name only -- no 
extension) into `*known-systems-with-bad-secondary-system-names*`.  
E.g.,

```
(setf (gethash "terrible-legacy-system" 
*known-systems-with-bad-secondary-system-names*) t)
```

... and that will suppress the warnings for you.

That set has "cl-ppcre" built into it, and I'm happy to add other 
systems that are in common use, but unmaintained.

I should put documentation of this into the manual....

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?

If you have a more specific idea for how this works, I'd be happy to 
discuss it further.

> 2. Get rid of upgrade. Upgrade feature requires to maintain a 3d array
> of possible cases, where dimensions are "old asdf version", "new asdf
> version" and "lisp implementation". It is hard to maintain and it will
> get harder and harder to maintain as the time goes on. Also upgrade is
> a good test of CLOS, but running tests at the very beginning of image
> bootstrap is not a good idea because there is no e.g. SLIME to work
> with convenience.

I don't know about doing away with upgrade, but certainly cutting 
**way** down on the upgrades we support is a good idea.  For CMUCL, we 
now only test and support 3.3.0+

I'm willing to do that for many more implementations, if I can figure 
out what ASDF versions they are shipping on what target platforms.

>
> 3. Last, but most important actually. Prioritize manual, FAQ, Wiki and
> all like this.

I'm ok with that, but I don't have the time for an end-to-end rewrite of 
the manual.  Note that I am also going to integrate **everything** into 
the manual, because I don't have the time to support more than one 
documentation set (e.g., Fare's Markdown stuff will get folded into the 
manual).

Part of the problem is that the manual doesn't have a clear structure.  
It shoold somehow start off by teaching only the basics, in a very 
brief discussion, then get to more advanced topics, then the object 
model, and stuff that only an extender, developer, or maintainer would 
want to know.  But it's quite possible I will retire or die before I 
manage to do that level of rewrite.

Restructuring is *really* not something that Texinfo makes easy, but 
Texinfo seems to be the worst documentation system ... except for all 
the other ones.

A contribution I would *love* to have is an adaptation of the SBCL 
manual code that extracts symbols and docstrings for inclusion in 
Texinfo.  At one point I looked into Didier's library (DecIt, I think?), 
but while it's good at extraction, I couldn't see how what it extracts 
could be moved around and integrated with large blocks of text.

I'm happy to accept FAQ suggestions and get them into the manual.
>
> Instead, when loading asdf, allow the user to pass the parameter that
> fills asdf database with the initial loaded system information. It
> would be also good to have an utility to extract this database from
> some old asdf versions. This way we have a slight chance to make
> things easier, upgrade process explicit and under user's control.


I'm not exactly sure what is meant by the above.

I have a number of different projects I work on, each with their own set 
of libraries.  I have made simple functions for each of these projects 
that populates `asdf:*central-registry*`, and when I sit down to work on 
one of these systems, I just invoke that function.  That's always been 
sufficient for me.  So something like:

```
CL-USER> (shop2)
"SHOP2 libraries available."
NIL
CL-USER> (asdf:test-system "shop2")
....
```

I still use `*central-registry*` for that because (1) I wrote it before 
Fare's new DSL was available and (2) I really don't have a handle on how 
to debug DSL-based configuration when it goes wrong (and configuration 
by environment variable is even more difficult, because the debugging 
environment isn't available until after the environment variables have 
been processed).

I hope this is helpful,
R
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20190219/de66769c/attachment-0001.html>