Change:
}) ``` <del> ## Overriding packages in scope {#lisp-overriding-packages-in-scope} Packages can be woven into a new scope by using `withOverrides`: ``` let sbcl' = sbcl.withOverrides (self: super: { alexandria = super.alexandria.overrideLispAttrs (oldAttrs: rec { pname = "alexandria"; version = "1.4"; src = fetchFromGitLab { domain = "gitlab.common-lisp.net"; owner = "alexandria"; repo = "alexandria"; rev = "v${version}"; hash = "sha256-1Hzxt65dZvgOFIljjjlSGgKYkj+YBLwJCACi5DZsKmQ="; }; }); }); in builtins.elemAt sbcl'.pkgs.bordeaux-threads.lispLibs 0 ``` </del> ### Dealing with slashy systems {#lisp-dealing-with-slashy-systems} Slashy (secondary) systems should not exist in their own packages! Instead, they

Discussion:
I feel like the documentation isn't helping a lot on how I can use , or any other alternative library/packaging solution. I've been trying to figure out how to use - the project I'm trying to nix-ify is . issue should give an insight on what problem I'm dealing with - it's about the package . Alternatively, I've also tried replacing with , but then, it complains about the package missing. The three packages that I'm in need of: - -[x] checked [latest Nixpkgs manual] ([source][nixpkgs-source]) and [latest NixOS manual] ([source][nixos-source]) [x] checked [open documentation issues] for possible duplicates [x] checked [open documentation pull requests] for possible solutions [latest Nixpkgs manual]: [latest NixOS manual]: [nixpkgs-source]: [nixos-source]: [open documentation issues]: [open documentation pull requests]:
Hi Ashvith10 - lisp-modules doesn't use Quicklisp or ASDF's - instead, all systems are in the Nix store. You can discover what systems are packaged in : Then, you can build a wrapper like this: Then, you can load the systems like this: Notice that ASDF is 'ed directly instead of using - this is to ensure the same version of ASDF is used on run time as was used on build time. seems to already exist - I don't know if that's the version that you need?. and are not packaged yet. I'm not familiar with Lem build system but looks like we have to package a bunch of extensions For examples of how to package, see . You can start with , , and and work your way through the errors.
thanks for answer. However, looks like I'm in the wrong here - I should have updated my progress and the misinformation in the top post. and are the packages we're trying to make. The first one is the text editor for terminal, and the second one offers an interface using SDL.

The issue right now is when I try to run the build script, it fails because QL does not exist: As you can see here: This is the file we're trying to run to build: which is trying to run this file: Since we didn't need this (because the very packages were updated to the same commit in nixpkgs as mentioned here in the patch), I got rid of it in my personal copy of the project, them through the Nix packages. Now, here's where the problem starts: and Since ql:quickload isn't working, it fails here. These "packages" are in the root of the repo, and I'm not able to figure out how to add them.
We could try to avoid this build script, and use asdf:load-system instead. There were two other places with references to QL, I patched them out. To add Lem, we can do something like this : For now I'm running it like this: There is some warning about missing font, I skip it with space. I need some help packaging the extensions, it's a lot of work
thanks for helping out with the project, if you could just let me know what I'll have to work on, I'd love to add my own commits. But I'm still not able to grasp why we're creating extensions and adding them in ? and should only be exposed to the lem package, right? Wouldn't it be better to create asdf build system under the file? About the packages, here's what I had in mind - there will be three packages to choose from, lem (which will include both lem-ncurses and lem-sdl), lem-ncurses and lem-sdl. I'd rather that opt-in be provided for users. What do you think?
let's not discuss more about here, it's my bad that I didn't create a separate issue. I'll create one shortly under "package request" and tag you there. This was with regards to improving the documentation, especially in cases like this, where instructions from isn't clear, and we might want to improve on this.
With regards to the first few improvement I can think of is: In the above snippet, the symlink is missing. and Both of them don't work, if I just type it on my console.

I was however, able to figure out how to make the last one work - to and then run the command. There might be other such incomplete parts in the documentation that I've forgotten, because I've not touched in two weeks.
thanks for catching that, I fixed those issues in commit regarding , I can see some further issues with it: It says that packages are 'imported', but doesn't say to where - perhaps we should say up front that the result of the import process is the file (this is mentioned further down, but maybe should be said earlier). Maybe also say that the goal of the import process is to save people some work of writing Nix expressions by auto generating those expressions and hoping they just work - I don't remember the numbers now, but a majority of them do work. It mentions the untracked "" file, but doesn't say that the file can be deleted at will It says that the maintainer should "re-run" the script, but doesn't explicitly say when - it's mentioned that the script pulls the latest data from Quicklisp, but maybe we should explicitly say that the script should run when there is a new Quicklisp release. This seems to be an issue with the section. In an ideal world, we just import the Quicklisp data, add native dependencies and everything works, but some packages decide to do weird stuff like creating files other than FASL during compilation. Other packages simply don't exist in Quicklisp. For these packages, we override them in Wchichever you prefer - though the convention so far has been to package things as one ASDF system per expression in . Then apps such as StumpWM or Nyxt (or Lem) can use things from as inputs. The advantage of having it in is that it will appear in all supported CL implementations: , , etc. If you place it somewhere else, you don't have access to , only to , which is specific to one CL.