En Taro Adun

[psionic-k]

En Taro Adun

[psionic-k]

All correct. The purpose of this discussion was to raise the subject, how are we doing Nix + Emacs and what is the goal.

I laid out my design here: https://github.com/positron-solutions/yakspkgs

I will be adding the proofs of concept written in Elisp soon. I'm going to use a combination of profile commands and pkgs.buildEnv https://nixos.org/manual/nixpkgs/stable/#sec-building-environment to implement the ideas.

[akirak]

There is nix-straight which is used by nix-doom-emacs. Is that what you want (or close to it)?

The alternative nightmare is to focus on always using Nix to create Emacs + dependencies + 3rd party dependencies with no involvement from user-present Emacs usage and no benefit to user-present user experience.

Yes, this is the current status of my project, and I admit its developer experience is worse than straight.el. My plan is to add an Emacs frontend named twist.el for better integration with Emacs, but it is unusable right now.

I once used both Nix and straight.el simultaneously in my config, but it was confusing to have multiple revisions of the same packages in a single running session. You can use emacsWithPackages from Nixpkgs, but it is inconvenient when you have many custom packages. This is one of the reasons I created this project.

Alternatively, you can use straight.el all the way. It is a mature package manager with a lot of features, including support for custom build instructions (i.e. :pre-build and :post-build). There is nothing wrong with it. It's just not Nix.

Both Guix and Nix will attempt to wrap Emacs independently with no inter-operation. Changing the loaded features in Emacs will always require evaluating and building in Nix.

This problem is not specific to my project, really. Any GUI application installed with Nix is like that. It might be possible to implement the feature you are requesting, but it requires design.

[psionic-k]

used by nix-doom-emacs. Is that what you want

Looks like it's intended to be used to update Emacs dependencies from Nix. This is probably closer to the nightmare scenario I'm describing. The world we want is to drive a Nix profile from Emacs. This would enable straight etc to fetch native dependencies from Nix pkgs without ever leaving Emacs.

I think profiles are perfect for this. They are gc roots. Changes to them are reflected across all processes and shells that point to them (atomic). They have generations for roll backs. We should really be looking at using profiles, not Nix expressions.

I have been making some progress using nix profile. If you read home manager source, it's not so complex. I think we can drive a profile from within Emacs

To get an idea of how to create a profile outside of home manager or NixOS switch, try the following:

nix profile install --profile emacs-profile nixpkgs#hello

The link farm created at emacs-profile should be familiar. Using Nix in this way installs arbitrary flake attributes into the profile and then you just append $PATH and now you are using the new profile. The home manager activation script, created by swtiching, is also pretty interesting material to work with.

Some more playing with profiles to explore
https://ianthehenry.com/posts/how-to-learn-nix/new-profiles/

While I believe Nix is good at providing, for example, an Emacs with straight and other bootstrap packages already installed, after Emacs can start up, any further use of Nix should be Emacs controlling a Nix profile and using straight to manage dependencies.

If we can do this, we can output a lock file format and use that to create Emacs derivations specific for CI usage. Locked Emacs doesn't need a profile because it's only useful for CI or sandbox testing. A profile is exactly what the dynamic experience of Emacs needs.

I saw the work going on in these related projects and felt the need to communicate what I believe the long term goals should be for ongoing work with Nix and Emacs. Nix is for dependencies, but I believe the package state of Emacs to be closer to database information, something we shouldn't aim to encode into Nix except for CI and sandbox testing use cases.

[akirak]

Use of Nix profiles may be a good idea.

So your goal can be broken down into the following two problems, right?

• Provide dependencies required in :pre-build and :post-build phases of individual packages by extending the :straight recipe format
• Install executables required by individual packages at runtime to a Nix profile

While the above ideas may make sense, I don't think there is an intersection between the idea and my existing code base. Perhaps you should discuss the issues in somewhere else (e.g. straight.el repository, the NixOS Discourse, NixPkgs, etc.)