En Taro Adun

[psionic-k]

Hello. English is not my first language.

I've been learning about some work involving straight and Nix. I want to get in touch regarding the goals. I believe there are two goals that will give the best long term benefit:

1. use Emacs to control a Nix profile. This would enable Emacs to use Nix to obtain 3rd party dependencies while the user is present.
2. Users should be able to decorate packages and a package header should be created to declare 3rd party, non-elisp dependencies. This way, either the user or the package maintainer can add a 3rd party dependency from either side, as the user or the package maintainer
3. Straight freeze could output extra information in the lock file designed for interpretation in a Nix expression, including 3rd party dependency information from 2
4. A nix expression should use the lock to deliver an Emacs + dependencies + 3rd party dependencies to a nix develop environment for CI or local "sandbox" testing (by setting user directory, not a Nix sandbox).

CI results from the lock file, which results from straight, which results from user-present activity. This is the way.

If you go the way that I'm prescribing, Guix will be able to consume the lock file and CI will be able to operate on Guix or Nix principles from a single lockfile, and there will be one system instead of two. As more packages accumulate the proper 3rd party headers, as more translations of those headers are written for both Nix and Guix, it will become possible for users to install sufficient 3rd party dependencies using Nix or Guix, in both cases with the reproducibility of those systems.

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. The 3rd party dependencies will have zero motivation to add headers. 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. Such a system will never add value. It will be in a continuous state of failure because the principles of Nix will drive it forward while the lack of any user value will leave it unadopted.

[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.)

[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.