Question:
Project description An unofficial GoXLR App replacement for Linux, Windows and MacOS. Metadata homepage URL: source URL: license: MIT platforms: linux
Moving conversation back here to avoid spamming goxlr-utility maintainers :sweat_smile: I made a draft PR that you can find from It's closer to what the official .deb and .rpm packaging is doing, i.e. including some of the relevant resources, shell completion etc. I wouldn't mind adding you as a maintainer but to do that it probably requires adding you to the maintainer list as well. Should be easy to fix if you want to add PR to the branch.
Hey wow you are fast :D Yes, you can add me as a maintainer for this package. But as I understand it, I need to add me to the maintainer list first, right?
Hah, had some free time during the night and since I wanted to get my GoXLR setup working anyways thought I might as well sort this out. For the question: Yup, the requires to be on . The file itself lists the mandatory/optional fields in the metadata, but basically "a name and at least one contact/identity information" (e.g. a github id). Oh, and the list needs to stay in alphabetical order ^^ Feel free to make PR against this branch, I'll merge it as soon as I notice the PR :)
Added the module to the PR as well. I guess it might be hard to wait for someone with GoXLR to come in and review the PR (though I'd prefer someone to check that it doesn't violate any major guidelines) so if you don't mind I think it's possible for you to try it out and do a PR review, which likely speeds up the process at least :)
Managed to get the PR reviewed and should now be code-wise idiomatic enough to pass. I think based on the main thing remaining is getting thumbs up from you functionality-wise so that's it's not only "works on my machine" :sweat_smile:
I saw your PR and tried using nixpkgs-review to download it to my local machine and try to run it. I used these steps: Do you know if my approach is wrong? This is the first time I've tried a Nix PR. Unfortunately, I haven't found much information about it. EDIT: Got it working
Glad to hear you got it working! :) The nixpkgs-review tool seems nice, hadn't used it myself but for building the PR it seems to do exactly what one would expect. I guess in this case there's a limit what it can do though as the udev rules are being on the module side and it probably doesn't handle that so some manual work is required :shrug: But again, all is good since you did manage to test the build!

githubId = 1583484; name = "Andrey Golovizin"; }; <ins> errnoh = { github = "errnoh"; githubId = 373946; name = "Erno Hopearuoho"; }; </ins> ersin = { email = "me@ersinakinci.com"; github = "ersinakinci";


Question:
Project description An unofficial GoXLR App replacement for Linux, Windows and MacOS. Metadata homepage URL: source URL: license: MIT platforms: linux
Moving conversation back here to avoid spamming goxlr-utility maintainers :sweat_smile: I made a draft PR that you can find from It's closer to what the official .deb and .rpm packaging is doing, i.e. including some of the relevant resources, shell completion etc. I wouldn't mind adding you as a maintainer but to do that it probably requires adding you to the maintainer list as well. Should be easy to fix if you want to add PR to the branch.
Hey wow you are fast :D Yes, you can add me as a maintainer for this package. But as I understand it, I need to add me to the maintainer list first, right?
Hah, had some free time during the night and since I wanted to get my GoXLR setup working anyways thought I might as well sort this out. For the question: Yup, the requires to be on . The file itself lists the mandatory/optional fields in the metadata, but basically "a name and at least one contact/identity information" (e.g. a github id). Oh, and the list needs to stay in alphabetical order ^^ Feel free to make PR against this branch, I'll merge it as soon as I notice the PR :)
Added the module to the PR as well. I guess it might be hard to wait for someone with GoXLR to come in and review the PR (though I'd prefer someone to check that it doesn't violate any major guidelines) so if you don't mind I think it's possible for you to try it out and do a PR review, which likely speeds up the process at least :)
Managed to get the PR reviewed and should now be code-wise idiomatic enough to pass. I think based on the main thing remaining is getting thumbs up from you functionality-wise so that's it's not only "works on my machine" :sweat_smile:
I saw your PR and tried using nixpkgs-review to download it to my local machine and try to run it. I used these steps: Do you know if my approach is wrong? This is the first time I've tried a Nix PR. Unfortunately, I haven't found much information about it. EDIT: Got it working
Glad to hear you got it working! :) The nixpkgs-review tool seems nice, hadn't used it myself but for building the PR it seems to do exactly what one would expect. I guess in this case there's a limit what it can do though as the udev rules are being on the module side and it probably doesn't handle that so some manual work is required :shrug: But again, all is good since you did manage to test the build!

./services/audio/botamusique.nix ./services/audio/gmediarender.nix ./services/audio/gonic.nix <ins> ./services/audio/goxlr-utility.nix </ins> ./services/audio/hqplayerd.nix ./services/audio/icecast.nix ./services/audio/jack.nix


Question:
Project description An unofficial GoXLR App replacement for Linux, Windows and MacOS. Metadata homepage URL: source URL: license: MIT platforms: linux
Moving conversation back here to avoid spamming goxlr-utility maintainers :sweat_smile: I made a draft PR that you can find from It's closer to what the official .deb and .rpm packaging is doing, i.e. including some of the relevant resources, shell completion etc. I wouldn't mind adding you as a maintainer but to do that it probably requires adding you to the maintainer list as well. Should be easy to fix if you want to add PR to the branch.
Hey wow you are fast :D Yes, you can add me as a maintainer for this package. But as I understand it, I need to add me to the maintainer list first, right?
Hah, had some free time during the night and since I wanted to get my GoXLR setup working anyways thought I might as well sort this out. For the question: Yup, the requires to be on . The file itself lists the mandatory/optional fields in the metadata, but basically "a name and at least one contact/identity information" (e.g. a github id). Oh, and the list needs to stay in alphabetical order ^^ Feel free to make PR against this branch, I'll merge it as soon as I notice the PR :)
Added the module to the PR as well. I guess it might be hard to wait for someone with GoXLR to come in and review the PR (though I'd prefer someone to check that it doesn't violate any major guidelines) so if you don't mind I think it's possible for you to try it out and do a PR review, which likely speeds up the process at least :)
Managed to get the PR reviewed and should now be code-wise idiomatic enough to pass. I think based on the main thing remaining is getting thumbs up from you functionality-wise so that's it's not only "works on my machine" :sweat_smile:
I saw your PR and tried using nixpkgs-review to download it to my local machine and try to run it. I used these steps: Do you know if my approach is wrong? This is the first time I've tried a Nix PR. Unfortunately, I haven't found much information about it. EDIT: Got it working
Glad to hear you got it working! :) The nixpkgs-review tool seems nice, hadn't used it myself but for building the PR it seems to do exactly what one would expect. I guess in this case there's a limit what it can do though as the udev rules are being on the module side and it probably doesn't handle that so some manual work is required :shrug: But again, all is good since you did manage to test the build!

<ins> { config, lib, pkgs, ... }: let cfg = config.services.goxlr-utility; in with lib; { options = { services.goxlr-utility = { enable = mkOption { default = false; type = types.bool; description = lib.mdDoc '' Whether to enable goxlr-utility for controlling your TC-Helicon GoXLR or GoXLR Mini ''; }; package = mkPackageOptionMD pkgs "goxlr-utility" { }; autoStart.xdg = mkOption { default = true; type = with types; bool; description = lib.mdDoc '' Start the daemon automatically using XDG autostart. Sets `xdg.autostart.enable = true` if not already enabled. ''; }; }; }; config = mkIf config.services.goxlr-utility.enable { services.udev.packages = [ cfg.package ]; xdg.autostart.enable = mkIf cfg.autoStart.xdg true; environment.systemPackages = mkIf cfg.autoStart.xdg [ cfg.package (pkgs.makeAutostartItem { name = "goxlr-utility"; package = cfg.package; }) ]; }; meta.maintainers = with maintainers; [ errnoh ]; } </ins>


Question:
Project description An unofficial GoXLR App replacement for Linux, Windows and MacOS. Metadata homepage URL: source URL: license: MIT platforms: linux
Moving conversation back here to avoid spamming goxlr-utility maintainers :sweat_smile: I made a draft PR that you can find from It's closer to what the official .deb and .rpm packaging is doing, i.e. including some of the relevant resources, shell completion etc. I wouldn't mind adding you as a maintainer but to do that it probably requires adding you to the maintainer list as well. Should be easy to fix if you want to add PR to the branch.
Hey wow you are fast :D Yes, you can add me as a maintainer for this package. But as I understand it, I need to add me to the maintainer list first, right?
Hah, had some free time during the night and since I wanted to get my GoXLR setup working anyways thought I might as well sort this out. For the question: Yup, the requires to be on . The file itself lists the mandatory/optional fields in the metadata, but basically "a name and at least one contact/identity information" (e.g. a github id). Oh, and the list needs to stay in alphabetical order ^^ Feel free to make PR against this branch, I'll merge it as soon as I notice the PR :)
Added the module to the PR as well. I guess it might be hard to wait for someone with GoXLR to come in and review the PR (though I'd prefer someone to check that it doesn't violate any major guidelines) so if you don't mind I think it's possible for you to try it out and do a PR review, which likely speeds up the process at least :)
Managed to get the PR reviewed and should now be code-wise idiomatic enough to pass. I think based on the main thing remaining is getting thumbs up from you functionality-wise so that's it's not only "works on my machine" :sweat_smile:
I saw your PR and tried using nixpkgs-review to download it to my local machine and try to run it. I used these steps: Do you know if my approach is wrong? This is the first time I've tried a Nix PR. Unfortunately, I haven't found much information about it. EDIT: Got it working
Glad to hear you got it working! :) The nixpkgs-review tool seems nice, hadn't used it myself but for building the PR it seems to do exactly what one would expect. I guess in this case there's a limit what it can do though as the udev rules are being on the module side and it probably doesn't handle that so some manual work is required :shrug: But again, all is good since you did manage to test the build!

<ins> { lib , fetchFromGitHub , rustPlatform , installShellFiles , pkg-config , libpulseaudio , dbus , speechd }: rustPlatform.buildRustPackage rec { pname = "goxlr-utility"; version = "0.12.6"; src = fetchFromGitHub { owner = "GoXLR-on-Linux"; repo = "goxlr-utility"; rev = "v${version}"; hash = "sha256-vvaKCsqncRhag8IrS0AIfNqNHGU2WIvFaYISEVfUB2Y="; }; cargoHash = "sha256-Z57H5YeVYqlOaLRLaizVw8xTLstdjyXutnN7OgaUYOE="; buildInputs = [ libpulseaudio dbus speechd ]; nativeBuildInputs = [ pkg-config installShellFiles rustPlatform.bindgenHook ]; buildFeatures = [ "tts" ]; postInstall = '' install -Dm644 "50-goxlr.rules" "$out/etc/udev/rules.d/50-goxlr.rules" install -Dm644 "daemon/resources/goxlr-utility.png" "$out/share/icons/hicolor/48x48/apps/goxlr-utility.png" install -Dm644 "daemon/resources/goxlr-utility.svg" "$out/share/icons/hicolor/scalable/apps/goxlr-utility.svg" install -Dm644 "daemon/resources/goxlr-utility-large.png" "$out/share/pixmaps/goxlr-utility.png" install -Dm644 "daemon/resources/goxlr-utility.desktop" "$out/share/applications/goxlr-utility.desktop" substituteInPlace $out/share/applications/goxlr-utility.desktop  --replace /usr/bin $out/bin  --replace goxlr-launcher goxlr-daemon completions_dir=$(dirname $(find target -name 'goxlr-client.bash' | head -n 1)) installShellCompletion --bash $completions_dir/goxlr-client.bash installShellCompletion --fish $completions_dir/goxlr-client.fish installShellCompletion --zsh  $completions_dir/_goxlr-client completions_dir=$(dirname $(find target -name 'goxlr-daemon.bash' | head -n 1)) installShellCompletion --bash $completions_dir/goxlr-daemon.bash installShellCompletion --fish $completions_dir/goxlr-daemon.fish installShellCompletion --zsh  $completions_dir/_goxlr-daemon ''; meta = with lib; { description = "An unofficial GoXLR App replacement for Linux, Windows and MacOS"; homepage = "https://github.com/GoXLR-on-Linux/goxlr-utility"; license = licenses.mit; maintainers = with maintainers; [ errnoh ]; }; } </ins>


Question:
Project description An unofficial GoXLR App replacement for Linux, Windows and MacOS. Metadata homepage URL: source URL: license: MIT platforms: linux
Moving conversation back here to avoid spamming goxlr-utility maintainers :sweat_smile: I made a draft PR that you can find from It's closer to what the official .deb and .rpm packaging is doing, i.e. including some of the relevant resources, shell completion etc. I wouldn't mind adding you as a maintainer but to do that it probably requires adding you to the maintainer list as well. Should be easy to fix if you want to add PR to the branch.
Hey wow you are fast :D Yes, you can add me as a maintainer for this package. But as I understand it, I need to add me to the maintainer list first, right?
Hah, had some free time during the night and since I wanted to get my GoXLR setup working anyways thought I might as well sort this out. For the question: Yup, the requires to be on . The file itself lists the mandatory/optional fields in the metadata, but basically "a name and at least one contact/identity information" (e.g. a github id). Oh, and the list needs to stay in alphabetical order ^^ Feel free to make PR against this branch, I'll merge it as soon as I notice the PR :)
Added the module to the PR as well. I guess it might be hard to wait for someone with GoXLR to come in and review the PR (though I'd prefer someone to check that it doesn't violate any major guidelines) so if you don't mind I think it's possible for you to try it out and do a PR review, which likely speeds up the process at least :)
Managed to get the PR reviewed and should now be code-wise idiomatic enough to pass. I think based on the main thing remaining is getting thumbs up from you functionality-wise so that's it's not only "works on my machine" :sweat_smile:
I saw your PR and tried using nixpkgs-review to download it to my local machine and try to run it. I used these steps: Do you know if my approach is wrong? This is the first time I've tried a Nix PR. Unfortunately, I haven't found much information about it. EDIT: Got it working
Glad to hear you got it working! :) The nixpkgs-review tool seems nice, hadn't used it myself but for building the PR it seems to do exactly what one would expect. I guess in this case there's a limit what it can do though as the udev rules are being on the module side and it probably doesn't handle that so some manual work is required :shrug: But again, all is good since you did manage to test the build!

gox = callPackage ../development/tools/gox { }; <ins> goxlr-utility = callPackage ../tools/audio/goxlr-utility {}; </ins> gprolog = callPackage ../development/compilers/gprolog { }; gwe = callPackage ../tools/misc/gwe {


Question:
Another Problem:
patch welcome !
in , the call to generate completion should be moved to before the wrapping. And it should be called for luarocks-admin too thanks for noticing. Let me know if you wanna do it.
If u wanna test

sed -e "1s@.*@#! ${lua}/bin/lua$LUA_SUFFIX@" -i "$out"/bin/* substituteInPlace $out/etc/luarocks/*  --replace '${lua.luaOnBuild}' '${lua}' <ins> '' + lib.optionalString (stdenv.buildPlatform.canExecute stdenv.hostPlatform) '' installShellCompletion --cmd luarocks  --bash <($out/bin/luarocks completion bash)  --fish <($out/bin/luarocks completion fish)  --zsh <($out/bin/luarocks completion zsh) installShellCompletion --cmd luarocks-admin  --bash <($out/bin/luarocks-admin completion bash)  --fish <($out/bin/luarocks-admin completion fish)  --zsh <($out/bin/luarocks-admin completion zsh) '' + '' </ins> for i in "$out"/bin/*; do test -L "$i" || { wrapProgram "$i"


Question:
Another Problem:
patch welcome !
in , the call to generate completion should be moved to before the wrapping. And it should be called for luarocks-admin too thanks for noticing. Let me know if you wanna do it.
If u wanna test

lib.optionals (finalAttrs.pname == "luarocks-nix") [ file nix-prefetch-git ])} } done <del> '' + lib.optionalString (stdenv.buildPlatform.canExecute stdenv.hostPlatform) '' installShellCompletion --cmd luarocks  --bash <($out/bin/luarocks completion bash)  --fish <($out/bin/luarocks completion fish)  --zsh <($out/bin/luarocks completion zsh) </del> ''; propagatedBuildInputs = [ zip unzip cmake ];


Question:
A CLI program that renders Markdown timeline as HTML Announced: <!-- Describe the project a little: --Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin, ...
Since upstream has a this should be pretty simple using .

<ins> { lib , stdenv , fetchFromGitHub , buildNpmPackage }: buildNpmPackage rec { pname = "mw"; version = "unstable-2023-08-04"; src = fetchFromGitHub { owner = "mark-when"; repo = "mw"; rev = "a8676da1c7812a051456fabcb980c52a72f6e75e"; hash = "sha256-i95WuTH8qY+0PYQA9kOykQL+4d4oB2Hlvg9sfGtDeCo="; }; npmDepsHash = "sha256-D1hTaoM4j81qrrLMoKJ7OxJTfRoht3/yqgJs95EFxY4="; # correctly substitute the usage message postPatch = '' substituteInPlace src/index.ts  --replace  '.usage("$0' '.usage("mw' ''; meta = { changelog = "https://github.com/mark-when/mw/blob/${src.rev}/CHANGELOG.md"; description = "Markwhen CLI"; homepage = "https://github.com/mark-when/mw"; license = lib.licenses.mit; longDescription = '' Markwhen is an interactive text-to-timeline tool. Write markdown-ish text and it gets converted into a nice looking cascading timeline. ''; mainProgram = "mw"; maintainers = with lib.maintainers; [ dit7ya ]; }; } </ins>


Question:
A CLI program that renders Markdown timeline as HTML Announced: <!-- Describe the project a little: --Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin, ...
Since upstream has a this should be pretty simple using .

mutt-ics = callPackage ../tools/networking/mutt-ics { }; <ins> mw = callPackage ../tools/text/mw { }; </ins> mwic = callPackage ../applications/misc/mwic { pythonPackages = python3Packages; };


Question: bunx is missing in the bun package. - command must be present. - Please run and paste the result.

installPhase = '' runHook preInstall install -Dm 755 ./bun $out/bin/bun <ins> ln -s $out/bin/bun $out/bin/bunx </ins> runHook postInstall ''; passthru = {


Question: Package name: expressvpn Latest released version: 3.52.0.2 Current version on the unstable channel: 3.25.0.13 Current version on the stable/release channel: 3.25.0.13 Notify maintainers Note for maintainers: Please tag this issue in your PR.

let pname = "expressvpn"; <del> clientVersion = "3.25.0"; clientBuild = "13"; </del> <ins> clientVersion = "3.52.0"; clientBuild = "2"; </ins> version = lib.strings.concatStringsSep "." [ clientVersion clientBuild ]; expressvpnBase = stdenvNoCC.mkDerivation {


Question: Package name: expressvpn Latest released version: 3.52.0.2 Current version on the unstable channel: 3.25.0.13 Current version on the stable/release channel: 3.25.0.13 Notify maintainers Note for maintainers: Please tag this issue in your PR.

src = fetchurl { url = "https://www.expressvpn.works/clients/linux/expressvpn_${version}-1_amd64.deb"; <del> hash = "sha256-lyDjG346FrgT7SZbsWET+Hexl9Un6mzMukfO2PwlInA="; </del> <ins> hash = "sha256-cDZ9R+MA3FXEto518bH4/c1X4W9XxgTvXns7zisylew="; </ins> }; nativeBuildInputs = [ dpkg autoPatchelfHook ];


Question:
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.

# lisp-modules {#lisp} This document describes the Nixpkgs infrastructure for building Common Lisp <del> libraries that use ASDF (Another System Definition Facility). It lives in `pkgs/development/lisp-modules`. </del> <ins> systems that use [ASDF](https://asdf.common-lisp.dev/) (Another System Definition Facility). It lives in `pkgs/development/lisp-modules`. </ins> ## Overview {#lisp-overview} The main entry point of the API are the Common Lisp implementation packages <del> (e.g. `abcl`, `ccl`, `clasp-common-lisp`, `clisp` `ecl`, `sbcl`) themselves. They have the `pkgs` and `withPackages` attributes, which can be used to discover available packages and to build wrappers, respectively. The `pkgs` attribute set contains packages that were automatically imported from Quicklisp, and any other manually defined ones. Not every package works for all the CL implementations (e.g. `nyxt` only makes sense for `sbcl`). The `withPackages` function is of primary utility. It is used to build runnable wrappers, with a pinned and pre-built ASDF FASL available in the `ASDF` environment variable, and `CL_SOURCE_REGISTRY`/`ASDF_OUTPUT_TRANSLATIONS` configured to find the desired systems on runtime. With a few exceptions, the primary thing that the infrastructure does is to run `asdf:load-system` for each system specified in the `systems` argument to `build-asdf-system`, and save the FASLs to the Nix store. Then, it makes these FASLs available to wrappers. Any other use-cases, such as producing SBCL executables with `sb-ext:save-lisp-and-die`, are achieved via overriding the `buildPhase` etc. </del> <ins> themselves (e.g. `abcl`, `ccl`, `clasp-common-lisp`, `clisp`, `ecl`, `sbcl`). They have the `pkgs` and `withPackages` attributes, which can be used to discover available packages and to build wrappers, respectively. The `pkgs` attribute set contains packages that were automatically [imported](#lisp-importing-packages-from-quicklisp) from Quicklisp, and any other [manually defined](#lisp-defining-packages-inside) ones. Not every package works for all the CL implementations (e.g. `nyxt` only makes sense for `sbcl`). The `withPackages` function is of primary utility. It is used to build [runnable wrappers](#lisp-building-wrappers), with a pinned and pre-built [ASDF FASL](#lisp-loading-asdf) available in the `ASDF` environment variable, and `CL_SOURCE_REGISTRY`/`ASDF_OUTPUT_TRANSLATIONS` configured to [find the desired systems on runtime](#lisp-loading-systems). </ins> In addition, Lisps have the `withOverrides` function, which can be used to <del> substitute any package in the scope of their `pkgs`. This will be useful together with `overrideLispAttrs` when dealing with slashy ASDF systems, because they should stay in the main package and be build by specifying the `systems` </del> <ins> [substitute](#lisp-including-external-pkg-in-scope) any package in the scope of their `pkgs`. This will also be useful together with `overrideLispAttrs` when [dealing with slashy systems](#lisp-dealing-with-slashy-systems), because they should stay in the main package and be built by specifying the `systems` </ins> argument to `build-asdf-system`. ## The 90% use case example {#lisp-use-case-example}


Question:
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.

Then, in a shell: ``` <del> $ result/bin/sbcl </del> <ins> $ sbcl </ins> * (load (sb-ext:posix-getenv "ASDF")) * (asdf:load-system 'alexandria) ```


Question:
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.

let sbcl' = sbcl.withPackages (ps: [ ps.alexandria ]); in mkShell { <del> buildInputs = [ sbcl' ]; </del> <ins> packages = [ sbcl' ]; </ins> } ```


Question:
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.

## Importing packages from Quicklisp {#lisp-importing-packages-from-quicklisp} <del> The library is able to very quickly import all the packages distributed by Quicklisp by parsing its `releases.txt` and `systems.txt` files. These files are available from [http://beta.quicklisp.org/dist/quicklisp.txt]. </del> <ins> To save some work of writing Nix expressions, there is a script that imports all the packages distributed by Quicklisp into `imported.nix`. This works by parsing its `releases.txt` and `systems.txt` files, which are published every couple of months on [quicklisp.org](http://beta.quicklisp.org/dist/quicklisp.txt). </ins> The import process is implemented in the `import` directory as Common Lisp <del> functions in the `org.lispbuilds.nix` ASDF system. To run the script, one can </del> <ins> code in the `org.lispbuilds.nix` ASDF system. To run the script, one can </ins> execute `ql-import.lisp`: ``` <ins> cd pkgs/development/lisp-modules </ins> nix-shell --run 'sbcl --script ql-import.lisp' ``` The script will: 1. Download the latest Quicklisp `systems.txt` and `releases.txt` files <del> 2. Generate an SQLite database of all QL systems in `packages.sqlite` </del> <ins> 2. Generate a temporary SQLite database of all QL systems in `packages.sqlite` </ins> 3. Generate an `imported.nix` file from the database <del> The maintainer's job there is to: </del> <ins> (The `packages.sqlite` file can be deleted at will, because it is regenerated each time the script runs.) </ins> <del> 1. Re-run the `ql-import.lisp` script 2. Add missing native dependencies in `ql.nix` 3. For packages that still don't build, package them manually in `packages.nix` </del> <ins> The maintainer's job is to: 1. Re-run the `ql-import.lisp` script when there is a new Quicklisp release 2. [Add any missing native dependencies](#lisp-quicklisp-adding-native-dependencies) in `ql.nix` 3. For packages that still don't build, [package them manually](#lisp-defining-packages-inside) in `packages.nix` </ins> Also, the `imported.nix` file **must not be edited manually**! It should only be <del> generated as described in this section. </del> <ins> generated as described in this section (by running `ql-import.lisp`). </ins> ### Adding native dependencies {#lisp-quicklisp-adding-native-dependencies}


Question:
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.

The previous implementation of `lisp-modules` didn't fully trust the Quicklisp data, because there were times where the dependencies specified were not <del> complete, and caused broken builds. It instead used a `nix-shell` environment to </del> <ins> complete and caused broken builds. It instead used a `nix-shell` environment to </ins> discover real dependencies by using the ASDF APIs. The current implementation has chosen to trust this data, because it's faster to


Question:
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.

During Quicklisp import: <del> - `+` in names are converted to `_plus{_,}`: `cl+ssl`->`cl_plus_ssl`, `alexandria+`->`alexandria_plus` - `.` to `_dot_`: `iolib.base`->`iolib_dot_base` </del> <ins> - `+` in names is converted to `_plus{_,}`: `cl+ssl`->`cl_plus_ssl`, `alexandria+`->`alexandria_plus` - `.` in names is converted to `_dot_`: `iolib.base`->`iolib_dot_base` </ins> - names starting with a number have a `_` prepended (`3d-vectors`->`_3d-vectors`) - `_` in names is converted to `__` for reversibility ## Defining packages manually inside Nixpkgs {#lisp-defining-packages-inside} <del> New packages, that for some reason are not in Quicklisp, and so cannot be auto-imported, can be written in the `packages.nix` file. </del> <ins> Packages that for some reason are not in Quicklisp, and so cannot be auto-imported, or don't work straight from the import, are defined in the `packages.nix` file. </ins> In that file, use the `build-asdf-system` function, which is a wrapper around `mkDerivation` for building ASDF systems. Various other hacks are present, such as `build-with-compile-into-pwd` for systems which create files during <del> compilation. </del> <ins> compilation (such as cl-unicode). </ins> <del> The `build-asdf-system` function is documented with comments in `nix-cl.nix`. Also, `packages.nix` is full of examples of how to use it. </del> <ins> The `build-asdf-system` function is documented [here](#lisp-defining-packages-outside). Also, `packages.nix` is full of examples of how to use it. </ins> ## Defining packages manually outside Nixpkgs {#lisp-defining-packages-outside} Lisp derivations (`abcl`, `sbcl` etc.) also export the `buildASDFSystem` <del> function, which is the same as `build-asdf-system`, except for the `lisp` argument which is set to the given CL implementation. </del> <ins> function, which is similar to `build-asdf-system` from `packages.nix`, but is part of the public API. It takes the following arguments: - `pname`: the package name - `version`: the package version - `src`: the package source - `patches`: patches to apply to the source before build - `nativeLibs`: native libraries used by CFFI and grovelling - `javaLibs`: Java libraries for ABCL - `lispLibs`: dependencies on other packages build with `buildASDFSystem` - `systems`: list of systems to build </ins> It can be used to define packages outside Nixpkgs, and, for example, add them <del> into the package scope with `withOverrides` which will be discussed later on. </del> <ins> into the package scope with `withOverrides`. </ins> ### Including an external package in scope {#lisp-including-external-pkg-in-scope}


Question:
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.

}) ``` <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


Question:
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.

}) ``` <del> See the respective section on using `withOverrides` for how to weave it back into `ecl.pkgs`. </del> <ins> See the [respective section](#lisp-including-external-pkg-in-scope) on using `withOverrides` for how to weave it back into `ecl.pkgs`. </ins> Note that sometimes the slashy systems might not only have more dependencies than the main one, but create a circular dependency between `.asd`


Question:
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.

implementations (`abcl`, `ecl`, `sbcl` etc.): ``` <del> sbcl.withPackages (ps: [ ps.alexandria ps.bordeaux-threads ]) </del> <ins> nix-shell -p 'sbcl.withPackages (ps: [ ps.alexandria ps.bordeaux-threads ])' </ins> ``` <del> Such a wrapper can then be executed like this: </del> <ins> Such a wrapper can then be used like this: </ins> ``` <del> result/bin/sbcl </del> <ins> $ sbcl * (load (sb-ext:posix-getenv "ASDF")) * (asdf:load-system 'alexandria) * (asdf:load-system 'bordeaux-threads) </ins> ``` ### Loading ASDF {#lisp-loading-asdf}