emacs-twist/elisp-helpers

A Nix library for scraping Emacs Lisp package metadata

Twist Nix Library

Status

This repository is currently in alpha state. It has finished basic functionalities, but there is still room for improvement in API, and it completely lacks proper documentation:

• Functionalities: Good. The author builds his own config with twist, and the config is already almost as capable as the previous version which used straight.el. Additionally, NoMake is used in some packages. The basic use cases of twist.nix are covered.
• API: Unstable. It is mostly stable, but options may undergo changes in the future.
• Documentation: Poor. There is a branch. I will rework on it after I gain more confidence with the API.

Introduction

Twist.nix is a Nix library for building Emacs configurations with packages. It is an infrastructure for configuration (solely with this library) and package development (with nomake).

This repository is an integral component of emacs-twist project. The goal of the project is to provide an alternative Emacs ecosystem that uses Nix. It is experimental, but also aims to be useful.

There are several other components under development. See the following table for comparison with corresponding options:

Twist component	Description	Counterpart
twist.nix (this repo)	Build machinery	package-build
twist.el combined with nix3.el	Emacs package manager	straight.el, borg, etc.
nomake	Package development	cask

As a Nix library, Twist.nix is also an alternative to the Emacs wrapper (i.e. emacsWithPackages) on NixOS. Twist.nix depends on Nix utility libraries, but it does not depend on the wrapper.

The biggest difference betweeen twist and the wrapper is that twist is capable of building packages from upstream source repositories. On the contrary, the wrapper fetches pre-built package archives from for most ELPA and MELPA packages, which means it indirectly depends on package-build for MELPA packages.

Here building a package means mapping files into a flat directory, which takes little time. By being smarter in building packages from sources, twist has an advantage in working around existing packages and adding custom packages, like straight.el. It also allows usage for package development, which is what package-build does to cask.

With twist, it is easier to lock and update individual packages, because it tracks package versions in flake.lock. Twist.el, the package management frontend for Twist, should hopefully provide an experience on par with straight.el.

Twist can discover and build packages from the following sources:

• MELPA recipes (Git)
• ELPA external/core packages (Git)
• ELPA/MELPA archives (single elisp files and tarballs)
• EmacsMirror (Git)

To add custom packages to your configuration, you only have to define MELPA recipes and commit them to your repository. It can already build configurations with a few hundreds of packages from various registries (see examples).

Credits

Twist is a Nix re-implementation of package-build and replicates its build logic. It is also heavily influenced by the Emacs wrapper in nixpkgs, though twist was written from scratch and different in implementation.

elisp-helpers's Issues

En Taro Adun

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.

Support :git fetcher type

Failed to parse this recipe:

(discover-my-major :fetcher git :url "https://framagit.org/steckerhalter/discover-my-major.git")

Received the following error messages from elinter:

Linking package source files...
unpacking 'https://github.com/akirak/nix-elisp-helpers/archive/59a72e066c63f6540315c3b81ae252bb44e5d767.tar.gz'...
unpacking 'https://github.com/talyz/fromElisp/archive/aa3e65306d621975b346c894b4f288c283dfb524.tar.gz'...
error: Unsupported fetcher type: git
error: opening file '//boot/System.map-5.3.0-1035-azure': Permission denied
(use '--show-trace' to show detailed location information)

https://github.com/akirak/elinter-demo/runs/1082880717?check_suite_focus=true

Follow updates in package-build

There will be a change (melpa/package-build#68) in package-build. Specifically, the recipe spec is under a change (e.g. accepting multiple subdirectory/exclude patterns) at melpa/package-build@0adc96b. I haven't found a concrete example for these changes yet, but I will have to modify this library to cover the new spec.

Unlike the other parties following those updates, this library is written in Nix, so it is impossible to simply copy-and-paste the "expand a file spec" function written in Emacs Lisp.