0:39 - 1:23 holly molly, just like that he covered ALLL THE THREE/FOUR syntax in a smooth seamless story manner. thanks a lotttt for this. 1. minimal/direct nix expression 2. nix function expression 3. importing [2.] in flake 4. embedding this inside a standalone flake
I'm so happy for that as well. The documentation is vast, but shallow, with many sources to learn from. It's nice to have someone condense all the necessary information to get learn how to do specific things with very easy examples.
Awesome! Still working on getting use to nix to switch to it as my daily driver. Really interested in seeing more on how to build projects and push to the nix package manager for my own projects and projects I find that are not in the nix package manager yet
2:47 > _"to be explicit, we could also like $src/hw"_ 3:10 > _"if u dont specify a build phase, nix will attempt to use a Makefile from src dir"_ 4:26 > _"we can define our own list [phases] containing phase names, for easy learning derovations"_ ohw, niice. yeah, it makes much more sense in explicit manner while getting started.
3:10 _"if u dont specify a build phase, nix will attempt to use a Makefile from src dir"_ awesommme. super helpful for those of us beginners who like to use makefiles for easy understanding/overview & also compatibility with IDEs & editors etc.
Just a thing, I tried using cp $src/hello-world, but that didn't work, cuz cp needed "" in the source part, how do I fix that? I tried using "$src/hello-world" and "${src}/hello-world", but that wouldn't work.
0:49 hi! what does those curly braces {} between import and semicolon ; convey? i had to put "pkgs" at this place while importing my nix-file containing packages array. i.e. "let mp = import ./my-pkgs.nix pkgs; in ..." but i dont understand what part of syntax this is. or say, what the "pkgs" or curly braces is doing here.
1:44 _"there are also buncha optional keys"_ 1:58 it would be awesome if u showed the documentation before showing the demonstration. the experience with documentation for nix-pkgs (super frustrating) is exact opposite of xp with nixos-config (very good and smooth). so, showing the documentation/reference and _how_ to follow or _to which part_ of documentation's structure to pay attention to, would help new users a lotttt.
3:37 hi again. when to use the devShells.${system}.default vs packages.${system}.default? i mean, the devShell _has_ to be defined * for tools like debugger, linter, lang-servers, etc... * regardless of whether the package is built with manual make runs, or via nix build. so, what's the benefit of defining the "package" when doing iterative rapid development for learning the programming concepts (i.e. not in a hardcore project)? i have no problem defining even both, but i want to properly know the rationale behind. this may sound dumb, but i kinda can't see clearly.
the package is used for nix run. it is like, well yeah, a "package" of the project - so all the info required for its building and distribution. like pyproject is for python projects. the devShell is just for setting up the CLI environment. it has no relation to how the project is build via nix.
4:09 > _"we could put it in buildInputs, but better is nativeBuildInputs; to make it available in phases, not in runtime"_ umh, whatt? isnt the cowsay used in the program itself? so i'd think it would be required at runtime too no? i think it is smth like dynamic linking to a system path executable. but can u please expand on it?
As far as i understood it(and that is probably what @yash1152 is pointing at) buildInputs means "programs necessary during buildtime" and nativeBuildInputs" means "programs necessary during runtime". This becomes really valuable when you cross-compile, so compile on system a for usage on system b. Cowsay is used in the program, but it is not linked to the program, it gets called from a system-call. If cowsay were imported in the .cpp file it had to be linked
Is there an algorithm that will make the end-user not spend copious amounts of time clicking cat-related videos on RUclips - thereby ruining my productivity?
I tried splitting the default.nix to 3 files, one for each case, but for some reason, I get an error that those files don't exist, only default.nix works, do you know why?
Спасибо за такие классные видео! Можешь, пожалуйста, рассказать про создание единого окружения разработки (как я понял, для этого используют nix develop или nix shell). Мой самый главный вопрос в том, что там по умолчанию используется bash, но я хотел бы использовать свой конфиг zsh (это уже не nix way?).
Да, я планирую сделать видео про Nix shell & Nix develop, а запускать их с zsh совсем несложно. Там можно указать shell-hook, который запустит нужную программу, включая любые оболочки. Так как по умолчанию все переменные из окружения пользователя сохряняются при входе в nix shell, .zshrc тоже будет там работать.
mkDerivation wraps around the derivation function and provides common utilities such as g++. The build is executed in a sandboxed environment, where g++ is enclosed via mkDerivation.
I've seen some packages coming with a flake.nix in their repository. Could you please show in a video how to have a project with a flake.nix instead and how it is properly consumed on my own flake.nix? You are a good teacher btw. :)
Another comment just for the yt algorithm! Thank you for your work!
Thanks!
Pardon me, I'm just curious, are you from CIS countries? Your accent sounds familiar to me (well, I'm from Russia)
@@unknown-otter I'm from Ukraine
0:39 - 1:23 holly molly, just like that he covered ALLL THE THREE/FOUR syntax in a smooth seamless story manner. thanks a lotttt for this.
1. minimal/direct nix expression
2. nix function expression
3. importing [2.] in flake
4. embedding this inside a standalone flake
I'm so glad I found this channel, great explanations for something I know I've wanted to learn for a long time!
I'm so happy for that as well. The documentation is vast, but shallow, with many sources to learn from. It's nice to have someone condense all the necessary information to get learn how to do specific things with very easy examples.
Awesome explanation! loving the nix videos!
I am running Nixos-install as we speak, keep up the amazing work , thank you!
Awesome as always! It is like Nix inception, you wrap your binary in a wrapper of a wrapper...yes and then we have cowsay. I totally got it.
Haha, yes.
I think you provide the most valuable and smooth content about Nix! Your videos helped me a lot!
This is just amazing. It makes building simpler.
ManI love what you are doing for the community, no one can thank you enough for your work, I don't know what to say
Great video as always
Awesome! Still working on getting use to nix to switch to it as my daily driver. Really interested in seeing more on how to build projects and push to the nix package manager for my own projects and projects I find that are not in the nix package manager yet
You are incredible. Keep it up
2:47 > _"to be explicit, we could also like $src/hw"_
3:10 > _"if u dont specify a build phase, nix will attempt to use a Makefile from src dir"_
4:26 > _"we can define our own list [phases] containing phase names, for easy learning derovations"_
ohw, niice. yeah, it makes much more sense in explicit manner while getting started.
3:10 _"if u dont specify a build phase, nix will attempt to use a Makefile from src dir"_
awesommme. super helpful for those of us beginners who like to use makefiles for easy understanding/overview & also compatibility with IDEs & editors etc.
Amazing content, just what I wanted to understand.
Just a thing, I tried using cp $src/hello-world, but that didn't work, cuz cp needed "" in the source part, how do I fix that? I tried using "$src/hello-world" and "${src}/hello-world", but that wouldn't work.
0:49 hi! what does those curly braces {} between import and semicolon ; convey?
i had to put "pkgs" at this place while importing my nix-file containing packages array. i.e.
"let mp = import ./my-pkgs.nix pkgs; in ..."
but i dont understand what part of syntax this is. or say, what the "pkgs" or curly braces is doing here.
LETS GOOO
1:44 _"there are also buncha optional keys"_
1:58 it would be awesome if u showed the documentation before showing the demonstration.
the experience with documentation for nix-pkgs (super frustrating) is exact opposite of xp with nixos-config (very good and smooth).
so, showing the documentation/reference and _how_ to follow or _to which part_ of documentation's structure to pay attention to, would help new users a lotttt.
before or alongside showing the demonstration
3:37 hi again. when to use the devShells.${system}.default vs packages.${system}.default?
i mean, the devShell _has_ to be defined
* for tools like debugger, linter, lang-servers, etc...
* regardless of whether the package is built with manual make runs, or via nix build.
so, what's the benefit of defining the "package" when doing iterative rapid development for learning the programming concepts (i.e. not in a hardcore project)?
i have no problem defining even both, but i want to properly know the rationale behind.
this may sound dumb, but i kinda can't see clearly.
the package is used for nix run. it is like, well yeah, a "package" of the project - so all the info required for its building and distribution. like pyproject is for python projects.
the devShell is just for setting up the CLI environment. it has no relation to how the project is build via nix.
great stuff
You forgot to add this to the nix playlist iirc.
Done, thanks
Is there a way to use sudo inside the nix-shell -pure ? Even after having the package sudo would throw some errors
4:09 > _"we could put it in buildInputs, but better is nativeBuildInputs; to make it available in phases, not in runtime"_
umh, whatt? isnt the cowsay used in the program itself? so i'd think it would be required at runtime too no?
i think it is smth like dynamic linking to a system path executable. but can u please expand on it?
3:56 ...
As far as i understood it(and that is probably what @yash1152 is pointing at) buildInputs means "programs necessary during buildtime" and nativeBuildInputs" means "programs necessary during runtime". This becomes really valuable when you cross-compile, so compile on system a for usage on system b.
Cowsay is used in the program, but it is not linked to the program, it gets called from a system-call. If cowsay were imported in the .cpp file it had to be linked
hype
Is there an algorithm that will make the end-user not spend copious amounts of time clicking cat-related videos on RUclips - thereby ruining my productivity?
If you find one, tell me).
I tried splitting the default.nix to 3 files, one for each case, but for some reason, I get an error that those files don't exist, only default.nix works, do you know why?
If you are using git, make sure to git add them. Flakes don't see unstaged files.
@@vimjoyer That was the issue, ty!
How does nix know which commands to run from the Makefile?
you can find all the logic here: github.com/NixOS/nixpkgs/blob/master/pkgs/stdenv/generic/make-derivation.nix.
Спасибо за такие классные видео! Можешь, пожалуйста, рассказать про создание единого окружения разработки (как я понял, для этого используют nix develop или nix shell). Мой самый главный вопрос в том, что там по умолчанию используется bash, но я хотел бы использовать свой конфиг zsh (это уже не nix way?).
Да, я планирую сделать видео про Nix shell & Nix develop, а запускать их с zsh совсем несложно. Там можно указать shell-hook, который запустит нужную программу, включая любые оболочки.
Так как по умолчанию все переменные из окружения пользователя сохряняются при входе в nix shell, .zshrc тоже будет там работать.
Also interested in nix develop for my projects (:
How does it know what g++ is? Why did you not have to define it in the buildInputs or i guess the nativeBuildInputs
mkDerivation wraps around the derivation function and provides common utilities such as g++. The build is executed in a sandboxed environment, where g++ is enclosed via mkDerivation.
my question too @Vimjoyer
Why do you import default.nix rather than using callPackage?
Yeah, callPackage is preferred.
What about you rename your channel to nixjoyer instead of vimjoyer ? xD
I'd have to change avatar too
why not then @@vimjoyer
@@rotteegher39 I don't care about the name much, but some people like this one, and I wont just be making nix videos here.
respect +++ @@vimjoyer
b;eh comment just for the algorithm baba bleh
I've seen some packages coming with a flake.nix in their repository. Could you please show in a video how to have a project with a flake.nix instead and how it is properly consumed on my own flake.nix? You are a good teacher btw. :)