fosstodon.org is one of the many independent Mastodon servers you can use to participate in the fediverse.
Fosstodon is an invite only Mastodon instance that is open to those who are interested in technology; particularly free & open source software. If you wish to join, contact us for an invite.

Administered by:

Server stats:

10K
active users

#Nix

58 posts47 participants2 posts today
Replied in thread

@alios
GOAL: or Isolated , interoperable env , shells by path, w/ central config cc

envs need not be interoperaple for different langs , say cc has a "devenv.lib.mkshell" for a rust tool `x` which is a runtime dep of epkgs 'ey`for rust work
Now If I enter this devshell with nix `develop ` and do a ` cargo install x` here
path of x is
> .devenv/state/cargo-install/bin/
Do note that my PWD is not ${HOME} here.
> But if I do a cargo install x from ${HOME} , it ll be in ~/.cargo/bin
Now lets say I install a melpapackages `ey` with my dotfiles' emacs.nix "emacs overlay`
It may be
`ls ~/.emacs.d/elpa/ | grep ey.elc` iff it's byte-compiled.
ey won't find it `x` , till you explicitly add this emacs load-path or to NIX-BUFFER's default.nix list of deps /project [This is just for the projects of 1 lang , nearly any serious work has > = 2] ,
or write .envrc /per project , so no global devenv/devshell.
Not every dir need be byte compiled
Possible reasons
While -
1. Nix does follow the XDG specs, Emacs does not fully follow it for its configuration and data files.
2. NIx Does not follow FHS hierarchy, Emacs Does.
3. Nix build re reproducible.
4. Nix is content addressed , store (hashed) paths
nix-instantiate --eval-only --expr '(import <nixpkgs> {}).emacs.outPath', it could be emacs or go or cargo or whatever your need, it need not have .
Some of your emacs data can be here. But I care bout getting deps in the path

One possible way could be to write a global devshell just for my init.el and launch it from there. But it's not easily extendable , more langs' projects ll put me back to square one.
Just nix-buffer seems to unsustainable
#nix #emacs

Learned a neat #Nix trick: You can easily cross-compile all programs in Nixpkgs (as long as they support the target platform)!

So instead of `nix build nixpkgs#ripgrep`, to build ripgrep for Windows, you can use:

nix build nixpkgs#pkgsCross.mingwW64.ripgrep

Other example targets are:

- "aarch64-multiplatform" (64-bit ARM)
- "gnu32" (i686)
- "riscv64" (64-bit RISC-V)
- "musl64" (x86_64, using musl instead of glibc)

Many more are defined in this file: github.com/NixOS/nixpkgs/blob/

Nix Packages collection & NixOS. Contribute to NixOS/nixpkgs development by creating an account on GitHub.
GitHubnixpkgs/lib/systems/examples.nix at master · NixOS/nixpkgsNix Packages collection & NixOS. Contribute to NixOS/nixpkgs development by creating an account on GitHub.
Continued thread

Not really surprising though I guess, its the corporate way of doing things.
You do something shady, get called out, apologize in an hand wavy, noncommittal kind of way, promise to do better, and then instead of doing anything wait until it blows over and quietly bring the thing back.
It's really kind of a classic.

Replied to nebucatnetzer

@nebucatnetzer @arialdo I love the idea of #Nix, I'm just still unsure whether I'm tall enough to ride that ride :)

The couple of times I've attempted it, I get NixOS installed, start trying to cobble together a configuration file. Have it explode in a shower of sparks, lather rinse repeat ~ 10 more times. Make zero progress.

^
^
^

Maybe one day I'll be smart enough :)