New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Switch to using Nix flakes #253
Conversation
Someone has requested me to build this book, since they didn't have Nix. So when looking at the Nix expressions I found that there was only a shell.nix and the default.nix was essentially just aliasing the shell.nix but without the pinning. However, with Nix flakes we no longer need to do pinning like this and we instead have a flake.lock file, which essentially pins the corresponding revisions. I also added a default.nix, which uses flake-compat to make sure that nix-shell and nix-build work as before. Since so far the way to build the PDF(s) was to get into a Nix shell and run make accordingly. For me however it's unacceptable to build random code without the Nix sandbox, so while writing a proper default.nix I decided it would be better to turn it into a Nix flake. Apart from the previous ways to build this project we now have: $ nix develop # To get a Nix shell (similar to nix-shell but cached) $ nix build # The default edition $ nix build .\#ctfp-scala # The Scala edition $ nix build .\#ctfp-ocaml # The OCaml edition Signed-off-by: aszlig <aszlig@nix.build>
Oh wow, this is fantastic! I'll admit I haven't really touched the Nix build every since I first attempted to hack it together.... I wasn't even sure it was still building! Thanks very much!! |
@hmemcpy: Holy cow, that was quick, thanks! Btw. another advantage is that now the book can be built by simply issuing: $ nix build github:hmemcpy/milewski-ctfp-pdf |
😮 This is amazing, really :) Thank you for the PR! |
I'm wondering if we could do that in Github actions as well :-) |
@drupol: You mean using something like https://github.com/marketplace/actions/install-nix? If yes I could give it a try, although I'm no expert when it comes to GitHub actions. |
Yeah something like that. I would be nice to see if it's better to use nix within Github actions to build the PDFs. IMHO, I don't think we should change something and having both system is perfectly fine! |
When switching the Nix expression to use Nix flakes, someone commented[1] that it *might* be a good idea to also use it for GitHub Actions. Since I personally build almost everything using Hydra, I don't have a lot of experience with GitHub Actions, so I'll give it a try... TODO: Reword this commit accordingly! [1]: hmemcpy#253 (comment) hmemcpy#253 Signed-off-by: aszlig <aszlig@nix.build>
This is partially implementing a comment[1] from @drupol on a pull request switching to use Nix Flakes: > I'm wondering if we could do that in Github actions as well :-) Right now only the builds and the artifact upload work, since there is still an issue to solve with the artifacts. Looking at the builds from the master branch, the artifacts generated during the normal builds are real PDF files with the right mime type. However, this isn't the case here and I haven't yet figured out why this is the case, since what we get instead are ZIP files. I also removed the dependencies job, since all information we need for builds and for generating artifacts/releases can be fetched via nix-instantiate. [1]: hmemcpy#253 (comment) Signed-off-by: aszlig <aszlig@nix.build>
Someone has requested me to build this book, since they didn't have Nix.
So when looking at the Nix expressions I found that there was only a
shell.nix
and thedefault.nix
was essentially just aliasing theshell.nix
but without the pinning.However, with Nix flakes we no longer need to do pinning like this and we instead have a
flake.lock
file, which essentially pins the corresponding revisions.I also added a
default.nix
, which usesflake-compat
to make sure that nix-shell and nix-build work as before.Since so far the way to build the PDF(s) was to get into a Nix shell and run make accordingly. For me however it's unacceptable to build random code without the Nix sandbox, so while writing a proper
default.nix
I decided it would be better to turn it into a Nix flake.Apart from the previous ways to build this project we now have: