recordgroovy has quit [Remote host closed the connection]
CrashTestDummy2 has joined #commonlisp
CrashTestDummy has quit [Ping timeout: 252 seconds]
montxero has quit [Read error: Connection reset by peer]
montxero has joined #commonlisp
waleee has quit [Ping timeout: 252 seconds]
elderK has joined #commonlisp
<beach>
Good morning everyone!
semz has quit [Ping timeout: 256 seconds]
<elderK>
Moin beach :)
semz has joined #commonlisp
robin has quit [Remote host closed the connection]
robin has joined #commonlisp
Skyfire has joined #commonlisp
montxero has quit [Read error: Connection reset by peer]
montxero has joined #commonlisp
Bike has quit [Quit: Connection closed]
JoshYoshi has joined #commonlisp
JoshYoshi has quit [Remote host closed the connection]
Josh_2 has quit [Ping timeout: 252 seconds]
Zianic has joined #commonlisp
robin has quit [Remote host closed the connection]
igemnace has quit [Ping timeout: 252 seconds]
lisp123 has joined #commonlisp
Inline has quit [Quit: Leaving]
lisp123 has quit [Ping timeout: 250 seconds]
<susam>
Good morning, beach!
igemnace has joined #commonlisp
cjb has quit [Quit: rcirc on GNU Emacs 28.0.50]
Skyfire has quit [Quit: brb]
shka has joined #commonlisp
Jach has quit [Quit: Leaving.]
Jach has joined #commonlisp
amb007 has quit [Ping timeout: 240 seconds]
amb007 has joined #commonlisp
montxero has quit [Read error: No route to host]
montxero has joined #commonlisp
amb007 has quit [Ping timeout: 256 seconds]
amb007 has joined #commonlisp
akoana has left #commonlisp [#commonlisp]
amb007 has quit [Ping timeout: 240 seconds]
amb007 has joined #commonlisp
heisig has joined #commonlisp
amb007 has quit [Ping timeout: 252 seconds]
amb007 has joined #commonlisp
Cymew has joined #commonlisp
khrbt has quit [Ping timeout: 252 seconds]
khrbt has joined #commonlisp
silasfox has joined #commonlisp
lisp123 has joined #commonlisp
heisig has quit [Ping timeout: 252 seconds]
amb007 has quit [Ping timeout: 252 seconds]
amb007 has joined #commonlisp
heisig has joined #commonlisp
gaqwas has joined #commonlisp
Skyfire has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
wilfred has joined #commonlisp
pve has joined #commonlisp
amb007 has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
heisig has quit [Remote host closed the connection]
heisig has joined #commonlisp
heisig has quit [Read error: Connection reset by peer]
heisig has joined #commonlisp
<mfiano>
Am I correct in that most-specific-last ordering in only valid in conforming CL for simple method combinations, not standard?
cosimone has joined #commonlisp
<mfiano>
I am assuming as such since standard accepts no arguments for the :method-combination argument
heisig has quit [Remote host closed the connection]
heisig has joined #commonlisp
<beach>
Right, the standard method combination takes no arguments.
<flip214>
mfiano: the standard method combination is most-specific-first -- or do I understand your questions wrong?
lisp123 has quit [Ping timeout: 252 seconds]
treflip has joined #commonlisp
scymtym has quit [Ping timeout: 245 seconds]
pillton has quit [Remote host closed the connection]
heisig has quit [Quit: Leaving]
hendursa1 has joined #commonlisp
hendursaga has quit [Ping timeout: 276 seconds]
Th30n has joined #commonlisp
dra has joined #commonlisp
Qwnavery has joined #commonlisp
dre has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
ggoes has quit [Ping timeout: 240 seconds]
amb007 has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
asarch has joined #commonlisp
dre has quit [Quit: Leaving]
asarch has quit [Quit: Leaving]
scymtym has joined #commonlisp
attila_lendvai has joined #commonlisp
ggoes has joined #commonlisp
vats has joined #commonlisp
attila_lendvai has quit [Quit: Leaving]
attila_lendvai has joined #commonlisp
lisp123 has joined #commonlisp
shka has quit [Quit: Konversation terminated!]
silasfox has quit [Ping timeout: 250 seconds]
silasfox has joined #commonlisp
kakuhen has quit [Quit: Leaving...]
scymtym has quit [Ping timeout: 250 seconds]
<lukego>
Hey, on the topic of Quicklisp/CLPM, am I crazy to think it would be nice to be able to specify a distribution via a criteria? The latest versions of all packages, except for these versions that are pinned, and on which these patches apply cleanly, such that test.lisp runs to completion?
attila_lendvai has quit [Quit: Leaving]
<lukego>
For example I write a test.lisp that loads my own application and runs its smoke tests, as the ultimate acceptance criteria, and I specify a few private patches or pinned versions that I need for stuff that's not compatible with upstreams, and then the package manager gets to work finding the latest package versions from Quicklisp/CLPM that will work.
attila_lendvai has joined #commonlisp
attila_lendvai has quit [Client Quit]
<lukego>
This would help me e.g. that I need at least three versions of McCLIM depending on context i.e. the CLIME branch for working on my own application, the mainline branch for reference, and the scytym branch for running e.g. SBCL-IR-VISUALIZER. and, for the latter two versions, I need one or two trivial patches applied to make it run on my local NixOS environment which I've been too lazy to upstream.
* lukego
looks at Qlot...
attila_lendvai has joined #commonlisp
dvush has joined #commonlisp
attila_lendvai has quit [Quit: Leaving]
attila_lendvai has joined #commonlisp
attila_lendvai has quit [Client Quit]
attila_lendvai has joined #commonlisp
dvush has quit [Quit: Client closed]
dvush has joined #commonlisp
dvush has quit [Client Quit]
lisp123 has quit [Remote host closed the connection]
frgo has quit [Remote host closed the connection]
frgo has joined #commonlisp
amb007 has quit [Ping timeout: 252 seconds]
amb007 has joined #commonlisp
wilfred has quit [Quit: Connection closed for inactivity]
amb007 has quit [Read error: Connection reset by peer]
<jackdaniel>
when you stare at the qlot, the qlot also gazes at you
didi has left #commonlisp [O bella ciao bella ciao bella ciao, ciao, ciao.]
* Cymew
pokes Qlot with his foot, quicking stepping backwards just to be sure
VincentVega has quit [Quit: ERC (IRC client for Emacs 27.2)]
silasfox has quit [Ping timeout: 252 seconds]
silasfox has joined #commonlisp
Qwnavery has quit [Read error: Connection reset by peer]
cranium has joined #commonlisp
cosimone has quit [Remote host closed the connection]
yitzi has joined #commonlisp
<mfiano>
lukego: That's exactly what I use CLPM for
lisp123 has joined #commonlisp
lisp123 has quit [Ping timeout: 252 seconds]
lisp123 has joined #commonlisp
lisp123 has quit [Ping timeout: 240 seconds]
<lukego>
mfiano: Good to know!
<mfiano>
Eric is pretty active on the Matrix channel if you have any questions.
* lukego
looks up what Matrix is..
<jackdaniel>
it is a federated im (not much unlike jabber)
Bike has joined #commonlisp
<lotuseater>
you can take the blue or the red pill
<hayley>
"And the ones that Mother gives you, don't do anything at all... "
shka has joined #commonlisp
makomo has joined #commonlisp
gko has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
lisp123 has quit [Ping timeout: 252 seconds]
tyson2 has quit [Quit: ERC (IRC client for Emacs 27.2)]
gko has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
Everything has quit [Ping timeout: 252 seconds]
Everything has joined #commonlisp
<etimmons>
lukego: I'm also happy to chat on IRC :)
<etimmons>
I don't think CLPM (nor Qlot) do exactly what you want, but are pretty close.
<etimmons>
CLPM doesn't apply patches, but it does let you use any git repo so you can apply your patches in a fork and then use that repo.
<lukego>
:-). I still haven't quite looked at CLPM yet, just feeling around for what problems each thing solves. for me I'm interested in the problem above ^ and also somehow having a read-write relationship with my dependencies i.e. easy way to fix problems in them directly instead of making workarounds in application code. I often end up doing 'git clone' and linking into ~/quicklisp/local-projects but then I'm kinda on my own.
<etimmons>
I can see a way to apply arbitrary patches without forking, but it'll require some other features that are in progress for CLPM.
<lukego>
The behavior that sounds attractive to me, at least, would be to fetch the main sources from upstream repo A and fetch a patch from private repo B. and complain or backtrack when the patch doesn't apply.
<lukego>
but in a perfect world there would be a lighter-weight solution that also works for projects that I haven't forked on github. not sure how though really.
<etimmons>
For the "such that test.lisp runs to completion" part, you'd have to script that yourself. I'd imagine it'd be a series of update calls (updating individual deps), testing the result, and rolling back to the older version if it fails.
<etimmons>
But the search space for that is potentially very large, so I only see it working if there's very little backtracking required.
<lukego>
yeah. I think something dumb would be appropriate, e.g. only considering the last 2-3 quicklisp releases of versions, or only considering versions between a known-working baseline verses newer versions
<etimmons>
I really want to make the read-write relationship with your deps smoother. CLPM has some features for that, but they're not the easiest to use. I think the next thing I've got planned in that area is a `hack` command that will automatically clone a dep for you and configure the bundle to use that clone for your local development.
<lukego>
and maybe that whole approach is overkill anyway. I just have a feeling of resistance to manually maintaining separate dependency trees for different projects, but that might actually not be much work
<lukego>
would it be unreasonable to always clone, and the hack comment just e.g. fetches history and maybe adds a writable remote?
<etimmons>
Ideally, `hack` would default to a project's upstream git repo. But that information isn't always easily available, so it'll be pretty much required to manually specify the repo to use for quite a while.
<lukego>
Generally when I `M-.' into a dependency I'd like to have some Git information available. I'm very often doing reflexively running Emacs commands for 'git blame' or 'git log' and being complained that the source is not in a git checkout.
<etimmons>
Oh, that's something I hadn't considered before. Right now, CLPM strips the repo when it installs something from git.
<etimmons>
But I guess it wouldn't be too hard to check out a working tree that just points to the bare repo CLPM has cloned locally....
* etimmons
goes to record this in an issue
<lukego>
I also have a layer of Nix *shudder* over all this that I have to contend with somehow, but that's a separate problem perhaps, and maybe Nix is becoming more trouble than it's worth in this context.
jpsa has joined #commonlisp
<etimmons>
That might also solve some other problems we discussed here yesterday regarding submodules and LFS
Th30n has quit [Quit: WeeChat 3.2]
lisp123 has joined #commonlisp
<lukego>
btw Julia has a nice bit of community infrastructure which is a bot that builds binaries for all the C/FFI dependency code and seems to do it in a neat way such that it all links together coherently and doesn't hit whatever random libraries are installed system-wide on the machine.
<lukego>
I assume that works well because it successfully installs on NixOS, which is the exactly the distro that breaks all kinds of binary distribution mechanisms, since it doesn't have any of the usual directories like /usr or /lib where people expect to find stuff.
<etimmons>
I'll have to look at that (but doubt I'll have the bandwidth to do much toward replicating it).
<lukego>
*nod* just mentioning it because it's the first time I saw such a thing.
<lukego>
(I'm not really sure how this normally works with Quicklisp, stuff has mostly worked for me provided I install a few C libraries when needed, and I do that easily enough with Nix)
<etimmons>
Honestly, I've been planning to stay far away from managing FFI deps... I've had the misfortune of using Python's Anaconda a few times (which attempts to do similar things) and have walked away scarred each time
<lukego>
yeah it seems like you have already bitten off plenty enough for one person anyway :)
<Shinmera>
I'm biting into that lemon myself
<Shinmera>
Well, not quite yet, but in some capacity in the future once the basis of Forge is done.
<etimmons>
Nice, I've been meaning to ask you about Forge
<Shinmera>
Some of its goals coincide with CLPM so I've been wanting to ask you, as well :)
<lukego>
btw this is the script that I use to setup my Lisp image at the moment. it depends on ql2nix which (IIRC) snapshots software versions by keeping track of everything that asdf/quicklisp installs. So this script just drives the front-end process of making that happen. https://gist.github.com/lukego/966e722cef988246882413a7dc4c6948
<etimmons>
I couldn't tell from the description and bits of code I looked at if it's aiming to be an ASDF alternative, or also take on typical "package manager" like tasks as well
<Shinmera>
It won't do fetching of packages and such. I feel that's an external task.
<Shinmera>
But it will be a build system in the very general sense of 'a thing that performs a set of steps to achieve a desired result' :v
<Shinmera>
At an advanced stage having package fetching integrated would be useful, to automate distributed building, for instance.
<lukego>
I'm idly wondering who would do what if CLPM catches on. for example, if I want to run SBCL-IR-VISUALIZER, would I as the user write a dependency description file for that? Or ideally would application developers distribute those? and if the latter would they compose e.g. with each other and my own when stitching a multi-application image together? and would that get so messy we miss the Quicklisp days of one unified dist?
<etimmons>
Cool. CLPM purposefully tries to stay far away from actually building the code. It just computes a grounded set of releases that satisfy some constraints, throws things in the right places, and then configures a build system (only ASDF at the moment) to find the things it's installed.
<Shinmera>
Right.
<Shinmera>
There's a lot of reasons why I'm building Forge, and one of them is so people can actually have multiple versions of a project 'visible' to the build system at once, and thus finally start writing version constraints into their deps.
<lukego>
that sounds kinda nice for me, since I have a bespoke build system based on nix already, and often end up fighting with other systems that have a build system integrated e.g. rust/julia/etc.
<etimmons>
What got me curious about Forge was that it seemed to have some constraint resolution logic as well. Is that so it can natively support multiple versions of a project?
<Shinmera>
:)
<etimmons>
ah, you answered my question as I wrote it :)
Inline has joined #commonlisp
<Shinmera>
Similar to CLPM I also want forge to be out-of-process, only sending commands to the client to do compilation/loading, to avoid poisoning the host with adjacent crap only needed to build things.
<etimmons>
I don't know if you've seen, but rpg and I are aiming to expand ASDF's version constraint language in the next release.
<Shinmera>
Another reason I want this is so I can cleanly deploy things and then load Forge later to do building on a deployed machine. My use-case being mods for Kandria.
<Shinmera>
I have not seen, no
<Shinmera>
As mentioned previously, I've been trying to wrap my brain around constraint resolution for some weeks now. I still don't have a solution I like.
jpsa has left #commonlisp [ERC (IRC client for Emacs 28.0.50)]
<etimmons>
Nice! I like that out of process model (obviously). Do you have any general purpose libraries made (or planned) for that communication? I'm starting to get to the point where I'd love to wrap up things like reporting error conditions between processes into a library. My current approach is a little ad-hoc
<Shinmera>
I've started on that in the Forge repo.
<Shinmera>
Nothing done or tested yet, though.
CrashTestDummy has joined #commonlisp
lisp123 has quit [Quit: Leaving...]
<etimmons>
I'll have to check the logs, I think I missed seeing anything about constraint resolution.
<etimmons>
lukego: I'm very hesitent to have CLPM's bundles compose. I think that's a one way ticket to madness. But mfiano has convinced me of the need to have some process that can examine the clpmfiles of your dependencies and suggest modifications to your project's clpmfile
CrashTestDummy2 has quit [Ping timeout: 252 seconds]
<etimmons>
Like "hey, your dependency is using a fork of blah, would you like to use the same fork?"
<etimmons>
My ideal scenario is that directives to check out dependencies from git are only for use in development. When you release a version of your project, it should depend only on dependencies that have been released and your .asd file contains all the appropriate version constraints
<etimmons>
But that starts to get into the question of how do you release projects. I'm not sure of the reddit/IRC overlap, but I posted some thoughts on that yesterday
<lukego>
I suppose that the natural way for me to interact with CLPM would be to use it to generate that file in the gist. I wonder if it would have all the information? Currently that data is generated by running quicklisp and hooking ASDF.
<lukego>
... or maybe ql2nix would just work with CLPM i.e. do the same ASDF-hooking to generate that data but via CLPM instead of Quicklisp.
<etimmons>
Yeah... writing concise documentation may not be my forte
<etimmons>
It doesn't seem to have all the same information, but comparable.
<etimmons>
Like I don't save the URL because I assume that can be gotten from the project index
cosimone has joined #commonlisp
<etimmons>
So the lock file only needs to pin to an (index, project, release) tuple
<lukego>
I'll have to let the gears in my brain turn a bit to understand what makes sense in my context. I'm a bit of a funny case since I'm already using the nix stuff that most nobody else uses. also the main practical issue I have with quicklisp is just that my ~/quicklisp/local-projects is just filling up with stale checkouts over time and causing me to drift away from the actual current quicklisp diff... but maybe the solution is
<lukego>
that I need to more actively upstream stuff
<etimmons>
Yeah, CLPM can only help with that so much I feel. Upstreaming is definitely the preferred long term solution
<lukego>
maybe also a software maturity thing. I'm mostly just hacking away in my home directory and wanting to avoid dependency hell. if I were shipping releases I'd be much more concerned about specific details and being accountable for the whole dist.
<lukego>
I can see that e.g. Shinmera would not want to accidentally pick up a new version of some binary blob that then crashes everyone's computers when they do a Steam update, etc.
<Shinmera>
lukego: My specific use case at the moment is for mods to specify constraints on game versions (and other mod versions).
<Shinmera>
lukego: I already control binaries separately pretty strictly myself, but yeah, that would be another use case later down the line I suppose.
<Shinmera>
Though generally I'm in the camp of "update as soon as possible rather than locking versions"
<lukego>
yeah. I like to keep up to date too, but like to avoid "hey this was working yesterday i have no idea what changed since then"
<Shinmera>
Right.
<etimmons>
I have some Gitlab CI jobs that run occasionally run `clpm bundle update -y` then run my system's tests.
<Shinmera>
Another reason why I want to make Forge is to have deterministic plan generation. Meaning Forge has a full separation between a 'planner' and an 'executor'. The plan does not take inventory of local files or anything, meaning you can deterministically ensure that your build operation will do the same things it would have done before. The executor then takes care of avoiding unnecessary steps.
<etimmons>
Helps me notice breakage, but also lets me always have a known working version
<Shinmera>
I'll make sure to read it though, thanks
<lukego>
They basically have a declarative description of "the build" - in their case including everything from the kernel to the C compiler to lib to X fonts - and then separately they execute on that build, in practice getting like 99.99% cache hits on the binaries, in a safe and disicplined way.
<Shinmera>
Right. That's the same thing I'm going for, then.
<lukego>
I know you don't like calling out to separate processes but there are a few misguided souls doing using Nix for Lisp stuff. I'd be happy to chat baout it :)
<Shinmera>
I'll shoot you a question if I have one :)
<lukego>
also from the perspective that if there is a better solution than nix i'd like to know about it...
<lukego>
but by far the biggest complication with Nix is just getting that declarative description of the system. sometimes it can be written by hand, sometimes it can be generated from suitable metadata, and often you need to actually run separate package managers (e.g. quicklisp) with a bunch of instrumentation to derive a declarative model from an operational one :)
tyson2 has joined #commonlisp
<lukego>
and this varies too. for Lisp I am personally running the instrumented tooling to capture the dependencies that I need. but for e.g. C, Emacs packages, R packages, Python packages, Haskell packages, the distro metadata is already upstream in Nix so you can just name the package you want and it knows how to get them.
<lukego>
(and has its own machinery for e.g. overriding versions and applying patches and stuff)
<lukego>
Oh, it would be cool if CLPM would be a vehicle for getting similarly good package definitions upstream into distros like Nix/debian/etc
<lukego>
(he says, not wanting to know -anything- about how other distros do their packaging)
<etimmons>
Getting that declarative specification from ASDF is a pain. It's both amazing and terrible that loading an .asd file can result in arbitrary code execution.
<Shinmera>
lukego: I have no idea about the process of nix package description, and I'm quite far away from a 'surface syntax' for Forge. I'm currently concentrating only on the internal protocol that descsribes objects and operations. Conceivably you could write an extension to Forge to generate the required components, rather than having to emit a description file.
cosimone has quit [Ping timeout: 256 seconds]
<Shinmera>
Or perhaps an extension could provide a syntax so simple that the only thing you'd have to put into a description would be "(project :via extension)" or something.
makomo has joined #commonlisp
makomo_ has joined #commonlisp
<etimmons>
CLPM does have an experimental interface to print that sort of dependency information. It's pretty trivial for simple systems, but in order to work for systems with :defsystem-depends-on or direct calls to asdf:load-system it requires actually installing those dependencies.
<etimmons>
But that part is split out into a separate library (not on QL) yet
<etimmons>
s/) yet/ yet)/
<lukego>
etimmons: that's another quirk with Nix. the actual build happens inside a locked-down sandbox with no network access and a minimal chroot. but that's the step after the messy bit that does the instrumentation to figure out what sources etc that sandbox needs to be populated wiht.
<etimmons>
And is fairly independent from CLPM, so you could install those dependencies using Nix, QL, whatevs
<etimmons>
If you're interested in it, I can add some actual documentation and examples of how to use it
<lukego>
I need to ponder a bit about my "read/write" problem. maybe there's a simple hack available e.g. automatically install two copies of the source, so that I can hack away on the code I see with `M-.' and still be able to do simple operations like diff/revert/upgrade
<lukego>
but if that means reinventing git it's probably on the wrong track..
<etimmons>
Shinmera: Nice. I might have gone that route if I had known about eclector at the time.
<etimmons>
But I'm pretty happy with what I've got now, especially since it's robust to people doing crazy customizations of their system class.
<etimmons>
But it can be much slower
<etimmons>
Especially if something like ironclad is dragged in via a :defsystem-depends-on
<lukego>
what makes ironclad slow?
<Shinmera>
compiling it takes a lotta time.
<mfiano>
It does a lot of compile time generation
amb007 has quit [Ping timeout: 240 seconds]
amb007 has joined #commonlisp
<lukego>
is that down to openssl? would a binary cache of the needed foreign code solve that problem? (and is this in scope for Forge?)
Cymew has quit [Ping timeout: 252 seconds]
<mfiano>
No, it doesn't depend on SSL. It generates a buncha LUTs and such
<lukego>
ah
<lukego>
binary cache of FASLs might be getting a bit silly
hhdave has quit [Ping timeout: 240 seconds]
hhdave has joined #commonlisp
tyson2 has quit [Quit: ERC (IRC client for Emacs 27.2)]
<lukego>
okay, it sounds like the problem that's most important to me, that has the fewest other people scratching their heads about right now, is the read/write aspect i.e. how do I smoothly make local hacks and asynchronously upstream them without making too much of a mess.
amb007 has quit [Ping timeout: 256 seconds]
amb007 has joined #commonlisp
char has quit [Ping timeout: 252 seconds]
les has quit [Quit: Adios]
les has joined #commonlisp
Skyfire has quit [Quit: WeeChat 3.2]
Skyfire has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
peterhil has quit [Ping timeout: 252 seconds]
amb007 has quit [Read error: Connection reset by peer]
cage has joined #commonlisp
amb007 has joined #commonlisp
tyson2 has joined #commonlisp
utis has joined #commonlisp
lisp123 has joined #commonlisp
attila_lendvai_ has joined #commonlisp
lisp123_ has joined #commonlisp
lisp123 has quit [Ping timeout: 240 seconds]
cosimone has joined #commonlisp
bhyde[m] has joined #commonlisp
tyson2 has quit [Quit: ERC (IRC client for Emacs 27.2)]
khrbt has quit [Ping timeout: 240 seconds]
makomo has quit [Quit: WeeChat 3.2]
Everything has quit [Quit: leaving]
khrbt has joined #commonlisp
azimut has joined #commonlisp
amb007 has quit [Ping timeout: 252 seconds]
amb007 has joined #commonlisp
cosimone has quit [Ping timeout: 252 seconds]
utis has quit [Ping timeout: 240 seconds]
utis has joined #commonlisp
char has joined #commonlisp
amb007 has quit [Ping timeout: 245 seconds]
amb007 has joined #commonlisp
scymtym has joined #commonlisp
gxt has quit [Remote host closed the connection]
gxt has joined #commonlisp
<cranium>
lukego: just to make it clear, you have heard of guix, right? Nix but with guile instead of its own language. Tho I have no idea which of the two is more advanced, but would bet on Nix
treflip has quit [Remote host closed the connection]
lisp123_ has quit [Remote host closed the connection]