flexi-streams.asd defines multiple ASDF system definitions

[slyrus]

Newer versions of ASDF have become more persnickety about having multiple ASDF systems in a single .asd file. The test stuff should probably be moved to its own .asd file.

[stassats]

I don't like fixing working stuff due to the changing tastes of the ASDF authors. I'd rather see ASDF being fixed.

[phoe]

That can be "worked around" by changing the name of system flexi-streams-test to flexi-streams/test.

[fjl]

The warning can also be removed by defining flexi-streams-test in its own .asd file. This is implemented in #23

[p-m]

Hi,
Any news about this issue?
TIA for any hints, Peter

[stassats]

ASDF is still producing bogus warnings.

[fjl]

IMHO the resolution of this issue is pretty clear, just merge #23 and this warning will be gone.

I doubt that ASDF will be changed back to allow for multiple systems with different names in one asd file.
They added this warning for a reason, it's not a 'taste' related decision. In order for ASDF to find the .asd file for a system, the names must match.

Right now, if you try to load "flexi-streams-test", it won't know where that's defined, so you cannot load it directly.

~ >> sbcl --noinform
* (asdf:load-system "flexi-streams-test")

debugger invoked on a ASDF/FIND-COMPONENT:MISSING-COMPONENT in thread
#<THREAD "main thread" RUNNING {7008964293}>:
  Component "flexi-streams-test" not found

You can only load it after loading the "flexi-streams" system:

~ >> sbcl --noinform
* (asdf:load-system "flexi-streams")
WARNING: System definition file #P"/Users/fjl/src/quicklisp/local-projects/flexi-streams/flexi-streams.asd" contains definition for system "flexi-streams-test". Please only define "flexi-streams" and secondary systems with a name starting with "flexi-streams/" (e.g. "flexi-streams/test") in that file.
T
* (asdf:load-system "flexi-streams-test")
;; [ additional warnings elided ]
T
*

The warning is just there to tell you this issue will happen, so why not fix it?

[fjl]

If you must have them in the same file, the other possible resolution is renaming the system to "flexi-streams/test".

ASDF does have functionality to handle multiple systems in one file, but in order for the .asd loader to work, the sub-system names must be separated from the common name using the / character.

This, too, is not really a matter of taste: they chose / as the separator because it is usually also the file path separator character, i.e. you cannot create a separate .asd file for such sub-systems (it would need / in basename).

[stassats]

Right now, if you try to load "flexi-streams-tests", it won't know where that's defined, so you cannot load it directly.

But you don't load flexi-streams-tests directly. (asdf:test-system :flexi-streams) works fine.

[rpgoldman]

How about this, @stassats -- if you don't like ASDF's maintenance, you take it over, and I quit? I'm tired of your attitude about this, and if you feel that strongly that it's important to block ASDF progress for ever, I could just quit maintaining it.

[stassats]

I don't see how a) that is progress b) how I'm blocking anything.

[rpgoldman]

Progress is that the ASDF-using community now have a clear way to handle multiple different systems in a single file.

Blocking things is that you refuse to accept patches that comply with this by making a one-character substitution of “/“ for “-“.

[stassats]

The old way works, and I'm not stopping anyone from using the new way.

[rpgoldman]

That is at best misleading, and at worst a bald-faced lie. You have publicly stated that your refusal to update systems like this is done in order to cause people to complain to me and get me to revoke this change. All you would have to do is merge trivial one-character changes that others have prepared for you, but yes, you block that.

[stassats]

Why don't you remove a single warning then? Should be trivial.

[rpgoldman]

Why do you feel it's appropriate -- even necessary -- for you to have a veto power over ASDF maintenance?

[stassats]

Dunno why I feel the freedom to express my dissatisfaction with things that appear to place unnecessary burden on me...

[phoe]

Might get burned by posting here, but here I go.

The real issue, as I understand it, stems from something earlier than a single-char change in flexi-streams, and I don't think this Mexican standoff of yours is going to benefit anyone in the long run.

One of you is trying to get things organized and updated across the broader Lisp world, the other follows the old and fruitful mantra of "don't break userspace". These two approaches obviously contradict each other in places. IMO the trick isn't to get you two to agree to something in flexi-streams, it's to figure out how exactly to align the goals of keeping Lisp things stable versus keeping Lisp things organized, and what should the processes for that be. And that's a broader discussion that needs to finally happen.

Otherwise, it's forever going to be flexi-streams getting broken by ASDF promoting a style warning to a full warning to an error and ASDF being prevented from being widely installable because of flexi-streams being non-loadable on it. Or, something worse than that, if things go too personal.

Please, take a step back and cool down, since more shots fired will help absolutely no one. And then let's figure something out about the elephant in the room which is how to find the middle ground between breaking projects that are too old and breaking projects that are too new. Like, figure it out with everyone's help, since I don't think the obviously big burden of that should rest on just the two of you.

[phoe]

And one more thing that I need to finally get off my chest - I'm pretty damn scared and saddened by the prospect of you two nuking it out between one another, especially since both of you are doing titanic work with regard to keep important software in the CL world running and modern and because the actual problem I see is bigger than a single character in flexi-streams and also bigger than which project ends up breaking another in the long run.

[gefjon]

the middle ground between breaking projects that are too old and breaking projects that are too new. Like, figure it out with everyone's help, since I don't think the obviously big burden of that should rest on just the two of you.

Obviously I have a bias in this issue, but I want to reiterate that the solution to this problem is trivial and obvious. Someone else made a small change and submitted it as a PR, and now Stas has to hit a single button in order for the warning to go away. He chooses not to do this because for some reason he thinks it's a bad thing that ASDF now warns users about a common pitfall which I, personally, have observed cause hard-to-debug system not found errors. If Stas changes his mind, there is a possibility that he will have to hit multiple, possibly even tens of buttons, and other library authors may have to make small, easy fixes to their code. If Robert changes his mind, an unknown but potentially large number of people will find that asdf:find-system fails to find their system with no obvious explanation why. This doesn't seem like a two-sided issue.

you two nuking it out between one another

Who's nuking it out? Stas is being childish rather than having useful technical discussions in appropriate forums; his doing that means more thankless work for Robert; Robert is not willing to do it.

[stassats]

The real issue, as I understand it, stems from something earlier than a single-char change in flexi-streams

Of course, it's not about the number of characters. It's about the frequent (in the past) breaking changes with each new ASDF version. And it's not just this system, I had dozens of these warnings from multiple independent projects, which were forced to update their code.

[stassats]

keep important software in the CL world running

It's just a warning, so everything is still running. Obviously, I would've changed it if it were a showstopper. But a warning allows me to be childish, rude, manipulative.

[gefjon]

I'm sure you're always welcome to discuss the merits and drawbacks of proposed breaking changes on the ASDF GitLab. And things are probably more likely to go your way, compared to your current strategy of antagonizing the maintainer.

[phoe]

It's about the frequent (in the past) breaking changes with each new ASDF version.

OK. That's approachable as a problem of coordinating software upgrades, and that's a relatively common problem even in the Lisp world. (Like, today I helped someone who complained about Symbol "%SIMPLE-FUN-NEXT" not found in the SB-KERNEL package because they finally upgraded their SBCL to newest but didn't upgrade their Slime/Swank from v2.23.)

At the moment it seems that, whenever ASDF wants to introduce something possibly breaking, it is willing, and has the manpower, to check all of Quicklisp for any projects that need to be updated, and to actually update these projects. Once that's done, ASDF can introduce a breaking change, and the presence of Quicklisp should make it easy to update broken projects, in order to avoid the fallout described in:

I had dozens of these warnings from multiple independent projects, which were forced to update their code.

This assumes that ASDF makes updates to projects it breaks and that Quicklisp is used to distribute fixed versions of software. I think both of these assumptions can hold in practice.

@stassats What are the other scenarios which you've seen that can result in brokenness? Do you mean any software outside Quicklisp (e.g. proprietary) which would need to reach to ASDF for support on its own because the software isn't there to be fixed by ASDF itself? You mentioned situations where SBCL upgraded ASDF and that resulted in broken code - was that because newer versions of software wasn't available at the time or possible to easily download e.g. via Quicklisp? If yes, what were the contexts of these situations and how could these be otherwise avoided in the future?

[stassats]

(Like, today I helped someone who complained about Symbol "%SIMPLE-FUN-NEXT" not found in the SB-KERNEL package because they finally upgraded their SBCL to newest but didn't upgrade their Slime/Swank from v2.23.)

I agree, I wouldn't have made that change. But Slime is too deep into SBCL internals so these things are inevitable.

What are the other scenarios which you've seen that can result in brokenness?

ASDF 1 to 3 there were a lot of changes, some understandable. And yes, it did include non-public code.

[phoe]

@gefjon I understand your position, but I'd also like to provide a little bit more context. I remember some situations from #sbcl on IRC in the past when Stas mentioned getting the flak for upgrading the default version of ASDF in SBCL. That upgrade it broke code that us over here weren't aware of but he - as an SBCL maintainer - got to hear complaints about it. Looking from that perspective, I can understand the position of not wanting to get any more, even if it manifests in something that - when pulled out of context - looks absolutely and utterly silly. Like a one-char patch.

I don't remember when exactly it was and I don't know if IRC logs from that time are available at all, but it isn't the important part; the real issue that I see is that actual coordination is required when it comes to keeping our permanently rolling-release Lisp world up and alive, especially with regard to breaking changes. Coordination requires communication, and communication is a persistently hard problem - especially if we indulge in pointing fingers instead of figuring out what's the real problem behind people throwing accusations at one another.

(This, and from what I got to know him, @stassats honestly isn't the kind of person who seems comfortable with using many words or sharing a lot about the flak he gets. I'm willing to try and spend a bit of my own strength and empathy to try and fill in the blanks with what I've seen.)

So, my proposal is, once again - let's cool down for a day or two, and approach this from a different perspective of "how to keep overall breakage low and the amount of work required to coordinate also low".

[daewok]

I wasn't really paying attention to ASDF development when ASDF 3 was coming out, which I believe is when a lot of the referenced breakage occurred. But I do know that there is a long history of ASDF developers opening issues and providing patches when they discover bugs or introduce breaking behavior. Sure, some things slip through the cracks, but to the best of my knowledge nothing has ever been intentionally broken without ample warning. So the behavior seen here when there is a clear improvement, ample warning time to adapt system definitions, and an extant patch that is just ignored is... frustrating, at best.

That said, there are definitely ways we can work together to help fill the gaps that ASDF misses in its testing. One thing I'd love to pursue is broader testing via CI. ASDF itself has recently gone through significant improvements in its CI. In particular, when SBCL enters its monthly freeze the Docker image we use for CI can begin building nightly. Any time the image changes (because there were new commits to SBCL), a webhook is fired that causes ASDF's tests to be run and an issue is opened if there's a failure.

I think that starting with the 3.4 series we can do something similar for ASDF. Any time a tag is pushed, we can fire a webhook that causes ASDF users to run their tests. If they notice something is broken and it's ASDF's fault they can open an issue. There's some questions on how to scale that process (e.g., do projects "register" with ASDF or is there some way they can self-register?), but I think it's doable.

[daewok]

One thing I'd love to pursue [...]

To be clear: I'm offering to head this up, based on my experience doing similar things with ASDF's CI. And as I've said elsewhere: this isn't a solution for the frustrations at hand and I don't want to add more to @rpgoldman's plate.

[fjl]

This issue can be closed now, @gefjon merged the PR.