Delete `nyxt-quicklisp.scm`

[aadcg]

Delete `nyxt-quicklisp.scm`

[aadcg]

Nix would work with Quicklisp (because, IIRC, Nix is really bad at handling Lisp packages)

We have the git submodules, for those who aren't on Guix. More generally, that's the whole purpose of the git submodules - avoiding Quicklisp and giving us finer control over what we ship. If someone buils or packages Nyxt with Quicklisp, they can do so, but that's not an official build.

[aartaka]

Yep, seems quite conflicting.

Nix would work with Quicklisp (because, IIRC, Nix is really bad at handling Lisp packages), but Guix definition is unlicely to influence Nix in any way (c.f. the argument of keeping Qt port to help a potential porting effort in #3121).

Unrelated: I remember that we had a Quicklisp interface somewhere. Was it removed due to irrelevance?

[jmercouris]

Yes, let us go ahead and remove it. We have also already removed the Quicklisp interface.

[Ambrevar]

There was a reason to be, for this module: to allow Guix-based devs to reproduce errors reported by people using Quicklisp.

That said, it's an admittedly limited scope, and if someone is using Quicklisp, it means they probably know enough Common Lisp to help us sufficiently to debug their issue.

[aadcg]

The dev team can't take the burden of maintaining all possible ways to install Nyxt.

We need a single point of reference for the CL dependencies, which is achieved by pinning versions as git submodules. On each release, they're bundled together with the Nyxt sources. Most GNU/Linux platforms that package Nyxt rely on this extended bundle. This tames the level of complexity and ensures that, with respect to the CL dependencies, we have full control over what we deliver.

Users may rely on quicklisp for a custom Nyxt install, but that is a non "official" method and no quality guarantees are provided.

[Ambrevar]

Sure thing, but my point was not about maintenance, it was about an easy way to reproduce the environment of the user when trying to fix their bug.

[aadcg]

My claim is that we don't need to reproduce such an environment. It concerns user endeavors that are not within our guarantee/responsibility zone.

[Ambrevar]

How would you reproduce a user bug then?

[jmercouris]

We don't support whatever is in the quicklisp dist, it may be fully incompatible or not even compile. It is outside the scope of what we do. If someone reports a bug running Nyxt via some unsanctioned method, we don't debug it, it is their problem.

[Ambrevar]

Isn't that a bit extreme?

[jmercouris]

I don't think it is very extreme. We have a product, we guarantee it works in ways X, Y, Z. We don't guarantee that it works in /all/ ways, and we can't afford to help people debug it on every kind of system and set-up. We don't make it hard for them to do so, we just don't offer them direct assistance. It seems fine to me.