Building pnpm2nix: yet another npm to nix tool
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Hose, Adam
There are already plenty of node package managers so why yet another one? This talk aims to give you an overview of the current npm-to-nix ecosystem, what tools there are, what the strengths/shortcomings of each one have and what pnpm is all about and how it pertains to nix. After that I will be talking you through what goes in to building pnpm2nix, what problems I had along the way and how nix/nixpkgs could improve to help such efforts along. - Bio: I love building software
 Okay, so next up is Adam and Adam is going to tell us about yet another NPM to Nix tool And I'm sure that by the end of the talk we're going to be convinced that we need yet another one So give it up for Adam So I'd like to just start by introducing myself I joined NixOS back in 2017 after I've done a lot of contributions for a while. I've been doing a lot of KDE packaging security fixes and also Sadly taking care of Node.js for a while So I have some goals with this talk it so introduce the Node.js packaging ecosystem and Teach you a little bit more about the module system how to the different packaging package managers and What I think to be the best one that has a lot of lot in common with Nix and I would like to inspire you to make your Own line to Nix tooling in pure Nix This looked different on my laptop before anyway So a short introduction to what what a Node.js module is So there are a bunch of different modules, but I'm gonna be talking module types, but I'm gonna be talking about It's the one way where you do require and without a path So one nice thing I think about Node.js in particular is how the require is just another function It's not like a language construct like in Python where you have an import. It's not very predictable You here is just a normal variable assignment. It's a function returning returning a module So what happens When you do require a module Well node.js walks first checks in your local node modules path, which everyone has seen before I guess it's not so well known that it also walks recursively upwards in the directory tree until it finds another node modules and Thirdly it falls back to the node path environment variable We can use this to some interesting effect, which we will see later The different node package managers does different things in terms of flattening so flattening means flattening that that dependency graph into a single level of dependencies Node.js tried to solve the issues of of Deep deep nesting which doesn't work well on Windows by doing this and and Also Some other some other aspects which make these deep nesting not work very well The sad thing about this flattening is that it results in in impurities So if if you have a flattened dependency tree Anything can require anything despite what is specified in the in the dependency specification Which is why did they never went with this non flattened structure in npm or yarn It's not entirely true, but mostly true Node.js was released back in 2009 back then it did not have a package manager and Was seen a bit of a Bit seen as a bit of a joke NPM entered the scene in 2010 it has resulted in Node.js becoming extremely popular I Guess most of you at some some level has to deal with that It's pretty npm. It's pretty bad in almost every way imaginable It's slow as a dog it keeps re-downloading dependencies at all times Packages are a big flat flattened mess Anything can require anything when you you don't have any any idea for what's actually gonna end up In in your dependency when you require dependency without looking in advance They did not have integrity checking for the longest time So you had no way of making sure that what you thought you were gonna download was actually what you ended up with Sandevan de Berg has made an amazing job on the node to nix tool Which I which is great. It's extremely compatible with with Node.js, but sadly it only has code generation as an option which Which I think is pretty Sad Considering that that you would now have to go through another step of generating the code before putting it into production Then a few years ago John entered the scene got extremely popular for some reason Tries to solve some of the performance issues of npm by using aggressive caching it does less flattening But still quite a lot They added lock files from the start to try to reach reproducible builds in some some at some aspect Deterministic dependency resolution so unlike npm which that where that changed every once in a while Also flattens dependencies It has a pretty pretty great next tooling made by Morty and I think Simba has also worked quite a lot on that Which can either do code generation or do runtime generation which means ingesting the the lock and and integrity files in pure nix And was a great source of inspiration for me how things could be and how I think most Know most tooling to nix should work We should not have to go through this massive code generation step It still flattens node modules at least so It's not ideal and it does some pretty complex things which leads to performance not being ideal PNPM is the new kid on the block actually. It's not very new. It was really it was a released about the same time as yarn, but sadly has not seen the same level of adoption It takes inspiration from IED which I think a lot of you have heard about Which explicitly said we take a lot of inspiration from nix in terms of purity and The main selling point that they advertise is performance It's incredibly fast if you try to install some dependency which doesn't pull in native stuff It's in the order of seconds Has quite a few things in common with nix has a centralized store Which means packages are shared if you install the same version of a package in multiple projects It keeps reusing the same Files on disk it does this by hard linking and and sim linking in combination depending on which file systems You use operating systems, etc So you can only require what you actually actively depend upon This breaks a bunch of note packages, but it's not as common as you would think It's pretty common that they include all their dependencies despite None of the tooling really thinking about that case That's not entirely true because anything can always Which I learned during this anything can always require whatever is dependent on by the top level application so that that was to solve the issues of Tooling like linter's having plugins and so if you install a plug-in into your top level the top level application That needs to be available Despite the application like ESLint not depending directly on it So the store structure of PNPM is Is abusing this this fact that no JS is walking recursively upwards the tree So what happens there is that when something has simulinked Yarks for example into its node modules No JS walks upwards Until it finds this what this node modules which includes Yarks plus sim links to all of its dependencies Which means that it's gonna short circuit at that point in the graph In not in your directory structure and not go looking for any other dependencies This means that we can get Pure purity at runtime when we do require We have something Akin to overrides, but they can only do graph rewriting So let's say a package called MS rest Azure is missing a Dependency on a package then we can rewrite the graph and include that dependency This happens More rarely than I thought it would so I do not even in really crazy project have to use overrides much and the nice thing It is goes into the Dependency lock file So I when I made my own next tooling I did not have to think about Supporting graph rewriting overrides because that was already implicit There was a lot of hard points about making this tooling One of the hardest is that the specifications in node.js are all wrong They they they say that you you don't you can't combine the two attributes like bin and bins in your package json file But in the same way you can't combine the two attributes like bin and bins in your package json file But in in reality there are a lot of packages depending on this kind of behavior The the specific a the specifications being wrong is pretty much a Rule rather than the exception so you do have to look at how applications actually behave rather than reading specifications when it comes to node.js Circular dependencies are way more common than I thought Which before I started doing this Project I had no clue that circular dependencies were even a thing in node.js I would imagine that that would lead to infinite recursion, but It does not they do have some some kind of Fake fixed point stuff going on Another thing is there are a large number of dependency types and a Large number of invariance of those like at the NPM registry You can't assume that anyone is using the upstream NPM registry that is customizable We have locally linked files which Inject sim links to other local locally linked projects There are get dependencies. There are a few other ones the nice thing about PMPM is that it resolves Github dependencies to their tarbles rather than using Git directly so you do get a nice nice performance boost out of that PMPM has pretty rich metadata So all dependencies are pre-resolved in in the dependency lock file Which is pretty nice so you can just have a look of that file and see exactly what what your directory structure is gonna look like on this Can what what thing is gonna end up? In your variables when you require something That is not always consistent though when it comes to things like like peer dependencies which are Which are meant for plugins so Again, let's say you depend on some linting linting feature That that typically goes into peer dependencies peer dependencies rather than dependencies because you can't mix and match Linters you can't mix and match loggers etc And next makes these traversing these graphs and working on these kind of graphs problem really really easy It's been truly been a breeze working with next with these kind of problems There are some pretty ugly aspects of what I had to do to get this working in the first place like using input I think you can see that you're using input So you can see that you're using input And you can see that you're using input And you can see that you're using input Ugly aspects of what I had to do to get this working in the first place like using input from derivation just to do Decoding of YAML files in next This is some somewhere I think we need to improve a lot in terms of being able to write plugins that that do Decoding of unsupported file formats and it I don't think it's a scalable approach to make everything we want to decode a built-in So PMPM to Nix in itself is quite a complicated beast, but using it is not I Took a lot of inspiration from what what Simba had done on yarn to Nick's hair so all you all you need to do to use it as is It's what you see on the screen everything all other necessary meta attributes are derived from from package JSON and shrink wrap YAML and if these two files are local so if you reference the source as a path rather than a fetch git or something You don't even have to use package JSON and shrink wrap YAML One of the more recent features I added to this thing is the ability to use it for to manage your development dependencies so What what do you see on the screen will result in is an environment where where you get the same version of of node you get a wrapped node interpreter with all the all the dependencies Exposed to you exactly as if they were installed with with PMPM I Find find this to be pretty great because I hate using any node package tooling I Do I did have to create my own ad hoc override mechanism to for you to be able to hook into the Override any package in the dependency graph. It is pretty awkward but I didn't find a better way to do this than Than to provide an attribute set Which takes a function of your derivation that all that you can override if Anyone is has any better ideas that would be pretty great This package in particular was Is a good example of why no JS is an insane ecosystem because The the override bits down here Is something I had to do because the package actually tries to download shared objects for your platform from the Internet To be able to do image manipulation Another big problem dealing with node.js packages is this PMPM to Nix is not very fast because it does faithfully make a Nix package out of every single NPM package that you pull in and In some projects this can be pretty hairy. I will show you a Customer project I've been working on where where the Dependency graph is the most insane I have ever seen just a moment And if we zoom in on this we can see that this is actually And this is not an unusual thing I found These are about eight eight about eight hundred fifty packages that ended up in this dependency graph So the performance of PMPM to Nix is not always great because of the large number of packages and the amount of Import from derivation that has to happen I'm hoping to improve upon this So the state of the tooling now is mostly correct It does mostly the right thing what it needs to do I have not found any new bugs in months It's mostly feature complete. It does support almost every feature that PMPM supports In has a pretty comprehensive test suite with which is extracted from real-world applications Interfaces like all the override interfaces are mostly stable that I do want to make a big change before I can say it's one at all And in the future I would like to abstract out some generic bits like The work I had to do to resolve circular dependencies Where I have to walk the dependency graph Identify cycles and merge the cycles into a single Nix package so from the point of Nix No, no a recursion is going on at all Closure size reductions as you could see that closure was pretty hairy All the native dependency tooling in in node.js is built with Python and Python does get pulled into the runtime of every single closure that pose in any native dependency as it is now That is something I would quite like to avoid. It's very big that Tarball resolution that matching GitHub revs to Tarballs is not entirely pure because PMPM upstream Currently does not have checksums for those And I would completely like to get rid of IFD if The big ticket item there is getting is getting YAML decoding in natively in Nix somehow I Would like to thank my previous employer for giving me a bunch of time to work on this at the company time and for the customer Which is using this in production And thanks to yarn to Nix for being an inspiration of how I think all this to Nix tooling should be The node.js module system, I think is actually pretty solid It's one of the nicer Interpreted languages out there in terms of module system But the ecosystem is completely insane and near unusable. I think If you do have to deal with it, which you probably do at some point do use PMPM I It's something that is truly appealing to me as a Nix Nix person So any questions right Thank you. Thank you very much And with you finish early we've got plenty of time for questions and people having questions So if everyone keep your arm raised, so I see we have to go next How are you handling What's a pre no post install scripts? I'm Shelling out to NPM in a bunch of spec in a in the pre-configure phase I know it's a in in to post install in the post install phase in in next you can So you're actually running the scripts that the modules have with them Yes, because yantanix for example takes the approach of just ignoring the scripts and then patching in Some of them again for the cases where you actually need them because most of them are like electron trying to download binaries or something like that and It could actually be easier if we try to always ignore them and for example now it's ass need some foreign function interface building and patching stuff like that again that because the far larger number of Scripts ones that we actually normally don't want to run probably Okay, yeah, I always always run the the scripts faithfully Yeah, I basically have two questions the first question is about the graph you showed earlier in your presentation did you Generate that from the runtime dependencies or the build time dependencies Can you say that again the graph that you showed earlier in your presentation? Oh, that was the runtime dependencies. Okay, because I think 800 dependencies is not really That much I would say But I think if you would compare that to the to the build time dependency graph Then I think you see you probably see a lot of packages that are involved. So perhaps you should also try that I Did it looks even more crazy and then my second question is basically Yeah, you also created a A Generator that basically produces nicks expressions. I'm actually maintaining two generators myself and there are yeah many more What could you basically? recommend Yeah, to the other people that develop generators I think one of your recommendations is that you preferably don't want to run a generator, right? Everything should work from nicks expressions. Yeah, but I think the difficulty is you currently rely on doing things on the instantiation phase, right? you You probably import generated nicks expressions, I think or import derivations or No, I think I use input from derivation for is only Doing yaml to JSON conversion so I can import the shrink wrap yaml into nicks Oh, okay, that's clear But are there any other things you would recommend that that you would like to see in the other generators? Mmm No, I would like to see less generators and more more of these kind of pure nicks tools Okay, yeah, all that shit. Thank you. Do Plugins work Yes Nothing special to be done just works out of the box Yeah, I do wrap wrap a bunch of binaries where Setting the node path appropriately to to get plugins to work properly to propagate them implicitly throughout the tree More questions So on the repository you say that BNPM doesn't include checksons for tar balls. Yeah, that that that was those get get hub tar balls. Yeah, but Do you think it can be included because yes, I plan to look at that right next week cool Nice, thanks More questions No, well in that case, thank you very much for your interesting talk
 Okay, so next up is Adam and Adam is going to tell us about yet another NPM to Nix tool  And I'm sure that by the end of the talk we're going to be convinced that we need yet another one  So give it up for Adam  So I'd like to just start by introducing myself I joined NixOS back in  2017 after I've done a lot of contributions for a while. I've been doing a lot of KDE packaging  security fixes and also  Sadly taking care of Node.js for a while  So I have some goals with this talk it so introduce the Node.js packaging ecosystem and  Teach you a little bit more about the module system how to  the different packaging package managers and  What I think to be the best one that has a lot of lot in common with Nix and I would like to inspire you to make your  Own line to Nix tooling in pure Nix  This looked different on my laptop before anyway  So a short introduction to what what a Node.js module is  So there are a bunch of different modules, but I'm gonna be talking module types, but I'm gonna be talking about  It's the one way where you do require and without a path  So one nice thing I think about  Node.js in particular is how the require is just another function  It's not like a language construct like in Python where you have an import. It's not very predictable  You here is just a normal variable assignment. It's a function returning returning a module  So what happens  When you do require a module  Well node.js walks first checks in your local node modules path, which everyone has seen before I guess  it's not so well known that it also walks recursively upwards in the directory tree until it finds another  node modules and  Thirdly it falls back to the node path environment variable  We can use this to some interesting effect, which we will see later  The different node package managers does different things in terms of flattening so flattening means  flattening that  that dependency graph into a single  level of dependencies  Node.js tried to solve the issues of  of  Deep deep nesting which doesn't work well on Windows by doing this and and  Also  Some other some other aspects which make these deep nesting not work very well  The sad thing about this flattening is that it results in in impurities  So if if you have a flattened dependency tree  Anything can require anything despite what is specified in the in the dependency specification  Which is why did they never went with this non flattened structure in npm or yarn  It's not entirely true, but mostly true  Node.js was released back in 2009 back then it did not have a package manager and  Was seen a bit of a  Bit seen as a bit of a joke  NPM entered the scene in 2010 it has resulted in Node.js becoming  extremely popular I  Guess most of you at some some level has to deal with that  It's pretty npm. It's pretty bad in almost every way imaginable  It's slow as a dog it keeps re-downloading dependencies at  all times  Packages are a big flat flattened mess  Anything can require anything when you you don't have any any idea for what's actually gonna end up  In in your dependency when you require dependency without looking in advance  They did not have integrity checking for the longest time  So you had no way of making sure that what you thought you were gonna download was actually what you ended up with  Sandevan de Berg has made an amazing job on the node to nix tool  Which I which is great. It's extremely compatible with with Node.js, but sadly it only has code generation  as an option  which  Which I think is pretty  Sad  Considering that that you would now have to go through another step of generating the code before putting it into production  Then a few years ago John entered the scene got extremely popular for some reason  Tries to solve some of the performance issues of npm by using aggressive caching it does less flattening  But still quite a lot  They added lock files from the start to try to reach reproducible builds in some some  at some aspect  Deterministic dependency resolution  so  unlike  npm which that where that changed every once in a while  Also flattens dependencies  It has a pretty pretty great next tooling made by Morty and I think Simba has also worked quite a lot on that  Which can either do code generation or do runtime generation which means ingesting the the lock and and integrity files  in pure nix  And was a great source of inspiration for me how things could be and how I think most  Know most tooling to nix should work  We should not have to go through this massive code generation step  It still flattens node modules at least so  It's not ideal and it does some pretty complex things which leads to performance not being ideal  PNPM is the new kid on the block actually. It's not very new. It was really it was a  released about the same time as  yarn, but sadly has not seen the same level of adoption  It takes inspiration from IED which I think a lot of you have heard about  Which explicitly said we take a lot of inspiration from nix in terms of purity and  The main selling point that they advertise is performance  It's incredibly fast if you try to install some dependency which doesn't pull in native stuff  It's in the order of seconds  Has quite a few things in common with nix has a centralized store  Which means packages are shared if you install the same version of a package in multiple projects  It keeps reusing the same  Files on disk it does this by hard linking and and sim linking in combination depending on which file systems  You use operating systems, etc  So you can only require what you actually actively depend upon  This breaks a bunch of note packages, but it's not as common as you would think  It's pretty common that they include all their dependencies despite  None of the tooling really thinking about that case  That's not entirely true because anything can always  Which I learned during this anything can always require whatever is dependent on by the top level application  so that that was to solve the issues of  Tooling like linter's having plugins and so if you install a plug-in into your top level the top level application  That needs to be available  Despite the application like ESLint not depending directly on it  So the store structure of PNPM is  Is abusing this this fact that no JS is walking recursively upwards the tree  So what happens there is that when something has  simulinked  Yarks for example into its node modules  No JS walks upwards  Until it finds this what this node modules which includes Yarks plus sim links to all of its dependencies  Which means that it's gonna short circuit at that point in the graph  In not in your directory structure and not go looking for any other dependencies  This means that we can get  Pure purity at runtime when we do require  We have  something  Akin to overrides, but they can only do graph rewriting  So let's say a package called MS rest Azure is missing a  Dependency on a package then we can rewrite the graph and include that dependency  This happens  More rarely than I thought it would so I do not even in really crazy project have to use overrides much and the nice thing  It is goes into the  Dependency lock file  So I when I made my own next tooling I did not have to think about  Supporting graph rewriting overrides because that was already implicit  There was a lot of hard points about making this tooling  One of the hardest is that the specifications in node.js are all wrong  They they they say that you you don't you can't combine the two attributes like bin and bins in your package json file  But in the same way you can't combine the two attributes like bin and bins in your package json file  But in in reality there are a lot of packages depending on this kind of behavior  The the specific a the specifications being wrong is pretty much a  Rule rather than the exception so you do have to look at how applications actually behave rather than reading specifications when it comes to  node.js  Circular dependencies are way more common than I thought  Which before I started doing this  Project I had no clue that circular dependencies were even a thing in node.js  I would imagine that that would lead to infinite recursion, but  It does not they do have some some kind of  Fake fixed point stuff going on  Another thing is there are a large number of dependency types and a  Large number of invariance of those like at the NPM registry  You can't assume that anyone is using the upstream NPM registry that is customizable  We have locally linked files which  Inject sim links to other local locally linked projects  There are get dependencies. There are a few other ones the nice thing about  PMPM is that it resolves  Github dependencies to their tarbles rather than using  Git directly so you do get a nice nice performance boost out of that  PMPM has pretty rich metadata  So all dependencies are pre-resolved in in the dependency lock file  Which is pretty nice so you can just have a look of that file and see exactly what what your directory structure is gonna look like on this  Can what what thing is gonna end up?  In your variables when you require something  That is not always consistent though when it comes to things like like peer dependencies which are  Which are meant for plugins so  Again, let's say you depend on some linting linting feature  That that typically goes into peer dependencies peer dependencies rather than dependencies because you can't mix and match  Linters you can't mix and match loggers etc  And next makes these traversing these graphs and working on these kind of graphs problem really really easy  It's been truly been a breeze working with next with these kind of problems  There are some pretty ugly aspects of what I had to do to get this working in the first place like using input  I think you can see that you're using input  So you can see that you're using input  And you can see that you're using input  And you can see that you're using input  Ugly aspects of what I had to do to get this working in the first place like using input from derivation just to do  Decoding of YAML files in next  This is some somewhere  I think we need to improve a lot in terms of being able to write plugins that that do  Decoding of unsupported file formats and it I don't think it's a scalable approach to make everything we want to decode a built-in  So PMPM to Nix in itself is quite a complicated beast, but using it is not I  Took a lot of inspiration from what what Simba had done on yarn to Nick's hair  so all you all you need to do to use it as  is  It's what you see on the screen  everything all other necessary meta attributes are  derived from from package JSON and shrink wrap YAML and if these two files are local  so if you reference the source as a path rather than a fetch git or something  You don't even have to use package JSON and shrink wrap YAML  One of the more recent features I added to this thing is the ability to use it for to manage your development dependencies so  What what do you see on the screen will result in is an environment where where you get the same version of  of node you get a  wrapped node interpreter with all the  all the dependencies  Exposed to you exactly as if they were installed with with PMPM I  Find find this to be pretty great because I hate using any node package tooling  I  Do I did have to create my own ad hoc override mechanism to for you to be able to hook into the  Override any package in the dependency graph. It is pretty awkward  but I didn't find a better way to do this than  Than to provide an attribute set  Which takes a function of your derivation that all that you can override if  Anyone is has any better ideas that would be pretty great  This package in particular was  Is a good example of why no JS is an insane ecosystem because  The the override bits down here  Is something I had to do because the package actually tries to download shared objects for your platform from the Internet  To be able to do image manipulation  Another big problem dealing with node.js packages is this  PMPM to Nix is not very fast because it does faithfully make a Nix package out of every single  NPM package that you pull in and  In some projects this can be pretty hairy. I will show you a  Customer project I've been working on where where the  Dependency graph is the most insane I have ever seen just a moment  And if we zoom in on this we can see that this is actually  And this is not an unusual thing I found  These are about eight eight about eight hundred fifty packages that ended up in this dependency graph  So the performance of PMPM to Nix is not always great because of the large number of packages and the amount of  Import from derivation that has to happen  I'm hoping to  improve upon this  So the state of the tooling now is mostly correct  It does mostly the right thing what it needs to do I have not found any new bugs in months  It's mostly feature complete. It does support almost every feature that PMPM supports  In has a pretty comprehensive test suite with which is extracted from real-world applications  Interfaces like all the override interfaces are mostly stable that I do want to make a big change  before I can say it's one at all  And in the future I would like to abstract out some generic bits like  The work I had to do to resolve circular dependencies  Where I have to walk the dependency graph  Identify cycles and merge the cycles into a single Nix package so from the point of Nix  No, no a recursion is going on at all  Closure size reductions as you could see that closure was pretty hairy  All the native dependency tooling in in node.js is built with Python and  Python does get pulled into the runtime of every single closure that pose in any native dependency as it is now  That is something I would quite like to avoid. It's very big that  Tarball resolution that matching GitHub revs to Tarballs is not entirely pure because PMPM upstream  Currently does not have checksums for those  And I would completely like to get rid of IFD  if  The big ticket item there is getting is getting YAML decoding in  natively in Nix somehow I  Would like to thank my previous employer for giving me a bunch of time to work on this at the company time and for the customer  Which is using this in production  And thanks to yarn to Nix for being an inspiration of how I think all this to Nix tooling should be  The node.js module system, I think is actually pretty solid  It's one of the nicer  Interpreted languages out there in terms of module system  But the ecosystem is completely insane and near unusable. I think  If you do have to deal with it, which you probably do at some point do use PMPM  I  It's something that is truly appealing to me as a Nix Nix person  So any questions  right  Thank you. Thank you very much  And with you finish early we've got plenty of time for questions and people having questions  So if everyone keep your arm raised, so I see we have to go next  How are you handling  What's a pre no post install scripts?  I'm  Shelling out to NPM in a bunch of spec in a in the pre-configure phase  I know it's a in in to post install in the post install phase in in next you can  So you're actually running the scripts that the modules have with them  Yes, because yantanix for example takes the approach of just ignoring the scripts and then patching in  Some of them again for  the cases where you actually need them because most of them are like  electron trying to download binaries or something like that and  It could actually be easier if we try to always ignore them and for example now it's ass  need some  foreign function interface building and  patching stuff like that again that  because the far larger  number of  Scripts ones that we actually normally don't want to run probably  Okay, yeah, I always always run the the scripts faithfully  Yeah, I basically have two questions the first question is about the graph you showed earlier in your presentation did you  Generate that from the runtime dependencies or the build time dependencies  Can you say that again the graph that you showed earlier in your presentation?  Oh, that was the runtime dependencies. Okay, because I think 800 dependencies is not really  That much I would say  But I think if you would compare that to the to the build time dependency graph  Then I think you see you probably see a lot of packages that are involved. So perhaps you should also try that I  Did it looks even more crazy and then my second question is basically  Yeah, you also created a  A  Generator that basically produces nicks expressions. I'm actually maintaining two generators myself and there are yeah many more  What could you basically?  recommend  Yeah, to the other people that develop generators  I think one of your recommendations is that you preferably don't want to run a generator, right?  Everything should work from nicks expressions. Yeah, but I think the difficulty is you currently rely on doing things on the instantiation phase, right?  you  You probably import generated nicks expressions, I think or import derivations or  No, I think I use input from derivation for is only  Doing yaml to JSON conversion so I can import the shrink wrap yaml into nicks  Oh, okay, that's clear  But are there any other things you would recommend that that you would like to see in the other generators?  Mmm  No, I would like to see less generators and more more of these kind of pure nicks tools  Okay, yeah, all that shit. Thank you. Do  Plugins work  Yes  Nothing special to be done just works out of the box  Yeah, I do wrap wrap a bunch of binaries where  Setting the node path appropriately to to get plugins to work properly to propagate them  implicitly throughout the tree  More questions  So on the repository you say that  BNPM doesn't include checksons for tar balls. Yeah, that that that was those get get hub tar balls. Yeah, but  Do you think it can be included because yes, I plan to look at that right next week cool  Nice, thanks  More questions  No, well in that case, thank you very much for your interesting talk
Adam_Hose_-_Building_pnpm2nix__yet_another_npm_to_nix_tool_uq5zi3_22DA_0_239.png Adam_Hose_-_Building_pnpm2nix__yet_another_npm_to_nix_tool_uq5zi3_22DA_240_551.png Adam_Hose_-_Building_pnpm2nix__yet_another_npm_to_nix_tool_uq5zi3_22DA_552_1079.png Adam_Hose_-_Building_pnpm2nix__yet_another_npm_to_nix_tool_uq5zi3_22DA_1080_1679.png Adam_Hose_-_Building_pnpm2nix__yet_another_npm_to_nix_tool_uq5zi3_22DA_1680_1727.png Adam_Hose_-_Building_pnpm2nix__yet_another_npm_to_nix_tool_uq5zi3_22DA_1728_6143.png Adam_Hose_-_Building_pnpm2nix__yet_another_npm_to_nix_tool_uq5zi3_22DA_6144_8147.png Adam_Hose_-_Building_pnpm2nix__yet_another_npm_to_nix_tool_uq5zi3_22DA_8148_10475.png Adam_Hose_-_Building_pnpm2nix__yet_another_npm_to_nix_tool_uq5zi3_22DA_10476_12011.png Adam_Hose_-_Building_pnpm2nix__yet_another_npm_to_nix_tool_uq5zi3_22DA_12012_13763.png Adam_Hose_-_Building_pnpm2nix__yet_another_npm_to_nix_tool_uq5zi3_22DA_13764_13919.png Adam_Hose_-_Building_pnpm2nix__yet_another_npm_to_nix_tool_uq5zi3_22DA_13920_14447.png Adam_Hose_-_Building_pnpm2nix__yet_another_npm_to_nix_tool_uq5zi3_22DA_14448_15047.png Adam_Hose_-_Building_pnpm2nix__yet_another_npm_to_nix_tool_uq5zi3_22DA_15048_16343.png Adam_Hose_-_Building_pnpm2nix__yet_another_npm_to_nix_tool_uq5zi3_22DA_16344_23051.png Adam_Hose_-_Building_pnpm2nix__yet_another_npm_to_nix_tool_uq5zi3_22DA_23052_23135.png Adam_Hose_-_Building_pnpm2nix__yet_another_npm_to_nix_tool_uq5zi3_22DA_23136_25547.png Adam_Hose_-_Building_pnpm2nix__yet_another_npm_to_nix_tool_uq5zi3_22DA_25548_26195.png Adam_Hose_-_Building_pnpm2nix__yet_another_npm_to_nix_tool_uq5zi3_22DA_26196_26387.png Adam_Hose_-_Building_pnpm2nix__yet_another_npm_to_nix_tool_uq5zi3_22DA_26388_26459.png Adam_Hose_-_Building_pnpm2nix__yet_another_npm_to_nix_tool_uq5zi3_22DA_26460_26735.png Adam_Hose_-_Building_pnpm2nix__yet_another_npm_to_nix_tool_uq5zi3_22DA_26736_26783.png Adam_Hose_-_Building_pnpm2nix__yet_another_npm_to_nix_tool_uq5zi3_22DA_26784_27035.png Adam_Hose_-_Building_pnpm2nix__yet_another_npm_to_nix_tool_uq5zi3_22DA_27036_27467.png Adam_Hose_-_Building_pnpm2nix__yet_another_npm_to_nix_tool_uq5zi3_22DA_27468_31067.png Adam_Hose_-_Building_pnpm2nix__yet_another_npm_to_nix_tool_uq5zi3_22DA_31068_31523.png Adam_Hose_-_Building_pnpm2nix__yet_another_npm_to_nix_tool_uq5zi3_22DA_31524_32435.png Adam_Hose_-_Building_pnpm2nix__yet_another_npm_to_nix_tool_uq5zi3_22DA_32436_32531.png Adam_Hose_-_Building_pnpm2nix__yet_another_npm_to_nix_tool_uq5zi3_22DA_32532_32579.png Adam_Hose_-_Building_pnpm2nix__yet_another_npm_to_nix_tool_uq5zi3_22DA_32580_35279.png Adam_Hose_-_Building_pnpm2nix__yet_another_npm_to_nix_tool_uq5zi3_22DA_35280_37775.png Adam_Hose_-_Building_pnpm2nix__yet_another_npm_to_nix_tool_uq5zi3_22DA_37776_38543.png Adam_Hose_-_Building_pnpm2nix__yet_another_npm_to_nix_tool_uq5zi3_22DA_38544_39671.png Adam_Hose_-_Building_pnpm2nix__yet_another_npm_to_nix_tool_uq5zi3_22DA_39672_39685.png