Please update ASDF

Bug #1826074 reported by Faré on 2019-04-24
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
SBCL
Undecided
Unassigned

Bug Description

As of 2019-04-23, SBCL uses ASDF 3.3.1 from November 2017, but ASDF 3.3.2 was released in May 2018 and 3.3.3 in March 2019, fixing many issues, including a few SBCL-specific ones. Please update to the latest ASDF release, whichever it may be by the time you close this bug. Note that ASDF 3.3.3 has notably been by included in CCL with no adverse reports and passes tests with cl-test-grid.

Nicolas Martyanoff (galdor) wrote :

ASDF still has not been updated, current version is 3.3.1.3 which is nearly two years old now. Would someone be open to a patch to (try) to update it ?

Stas Boukarev (stassats) wrote :

Each time ASDF is updated there are problems cropping up, some of which are not bugs but backwards incompatible changes. When somebody updates SBCL they may not want to update ASDF at the same time. With it being a third party project we cannot direct the same attention to quality or have the same policy towards backwards compatibility.
If anyone wants to update ASDF they can do it locally, to any version at any time, by loading it before the one bundled with SBCL.

Nicolas Martyanoff (galdor) wrote :

And here is a patch to update to ASDF 3.3.3. I'm not sure why the pull-asdf.sh script only consider major versions, but it's better than nothing.

On my system (Linux amd64), it builds successfully and all tests pass. I was also able to use the updated version of ASDF to load multiple systems without any issue.

Nicolas Martyanoff (galdor) wrote :

@stassats I'm not sure I understand. Since SBCL bundles ASDF, it becomes responsible for updating it. Of course never updating works, but then what is the point in bundling it?

Michał "phoe" Herda (phoe-krk) wrote :

According to historic data, ASDF updates tend to break various unrelated things for many people. Therefore, AFAIK, SBCL prefers to stay on an older version of ASDF and support it instead of jumping onto the newest one in order to avoid getting hit in the face with various ASDF breakages.

Stas Boukarev (stassats) wrote :

> but then what is the point in bundling it?

I would prefer not to, but it already is, so can't change that without breaking.

Nicolas Martyanoff (galdor) wrote :

I'll quote contrib/asdf/README.SBCL:

    The copies of asdf.lisp, asdf.texinfo, README.md, and LICENSE in this
    directory are complete and unchanged from the canonical versions at

      https://gitlab.common-lisp.net/asdf/asdf

    They may lag behind the upstream version by a few revisions (but
    shouldn't usually) but unless we've fouled up horribly, are not
    forked.

So apparently, SBCL does not stay on an older version by choice, and it is not "maintained" (as-in patched for SBCL) (which is a good since ASDF is used by other CL implementations).

Having ASDF bundled in CL implementations is a good thing because it reduces friction when trying to run anything Common Lisp (it's already bad enough that there is no way to really handle external dependencies). Now we may argue for months on the subject, but at the end of the day, ASDF is in CL implementations and it's not changing anytime soon.

Last versions of ASDF fix various bugs (e.g. on UIOP) and introduce the infortunately necessary *known-systems-with-bad-secondary-system-names* (which contains "cl-ppcre" by default, because you block a trivial patch on one of the most used systems). CCL already has ASDF 3.3.3 (for 8 months), so it's not like it's bleeding edge.

Are there other maintainers interested about this issue ?

Stas Boukarev (stassats) wrote :

Easy for you to say, you're not the one who has to face all the "Hi, I updated SBCL and now my program doesn't build anymore".

Nicolas Martyanoff (galdor) wrote :

I understand where you are coming from, but what is the alternative ? From what I can see, the ASDF repository is maintained, so if SBCL decides not to update anymore, it means one cannot rely on ASDF anymore (and no bundling your own ASDF in your systems is not a viable option because of the potential version conflicts; you can only load one single version in an image). In that case, why not announcing it clearly in the next release notes ? It would have really bad consequences for lots of people, but at least it would be clear.

I guess the most frustrating thing here is that there is no plan of any kind beyond "let's not do anything". For someone like me trying really hard to invest time and energy in Common Lisp, it is yet another signal I'm wasting my time.

Stas Boukarev (stassats) wrote :

You can update your own ASDF at any time, if your .asd depend on something new, insert a version assertion in them.

The goal of SBCL is to provide a CL implementation, and supplying third party software with it is out of such scope. The current ASDF works fine for SBCL's own needs, loading and building contribs, anything else is on the third party. Would've been nice if ASDF behaved differently, but it doesn't, so that's the current state. And I'm not the bigger person to accept that, so there's also that, but why should I?

Nicolas Martyanoff (galdor) wrote :

I can understand the argument.

Is there a reason not to close the ticket now that decision is clear ?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers