-
-
Notifications
You must be signed in to change notification settings - Fork 13.9k
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
Emacs infrastructure tracking issue #66303
Comments
Here's a weird one for you: I added Unfortunately, at runtime, So, to work around this, I override My questions, then, are:
|
IMHO:
1. Should these packages be declaring `org` in their `Package-Requires`? It is built-in, after all, but I suspect the Emacs packaging infrastructure assumes byte-compilation at runtime, and not the per-package byte-compilation stage performed by Nix.
Ideally, yes. (E.g. note that Haskell's Cabal packages do explicitly list versions of GHC builtin libraries they use.) In practice, making all of them obey this would be a lot of effort.
2. Do we need to manually add builtin libraries to `packageRequires` in case they are also published to an ELPA repo, in order to avoid errors as a result of byte-compilation?
I would rather not, too much effort.
3. Could we implicitly add certain builtin libraries from the resolved package set to all packages, in case they are loaded during byte-compilation?
Yes, ideally, there should be a `emacsBuiltin` attrset in `emacsPackages` (of a lowest priority for fixpointing) all pointing to current `emacs`, all of which can then be added as requisites to most packages by default. In such a setup we will, at most, need to manually override `org` and the rest of builtin packages present in other package sets so that they won't depend on themselves when fixpointing.
4. Is what we are doing correct at all? Should we defer byte-compilation to the `emacsWithPackages` builder itself, so it has a full `site-lisp` to resolve references during compilation?
That's an option that will solve your issue, but it will not solve the underlying issue. IMHO, broken byte-compilation is just a tip of an iceberg here. E.g., say one package hardcodes a path to binary/script from its dependency while being `make`ed.
|
My two cents:
|
Ran into an issue similar to #66303 (comment) while testing Emacs 27.0.90. In this case, some package is pulling in In this case, I don't want |
Hello, I am currently developing a Nix-based framework for testing Emacs packages, which uses Steve Purcell's nix-emacs-ci for backported previous versions of Emacs. It also uses emacs-overlay for a fresh set of packages required by a package under test. In some situations, however, it fails to run tests on older versions of Emacs, and this seems to be about built-in packages of Emacs. For example,
What would be a proper solution to run latest packages on older versions of Emacs? Is it necessary to override every package depending on such built-in packages, as suggested in #66303 (comment)? Or should I even create a different variant of package set for each version of Emacs? Would wrapping macro expansions with |
@tadfisher I just ran into the same problem. Did you ever resolve your case with |
Since all the big items are checked off I'm going to close this. |
I'm making an effort to clean up our Emacs packaging and use autogenerated packages whenever possible.
This is an incomplete list of things I want to achieve:
emacsPackages
& renameemacsPackagesNg
->emacsPackages
emacs-packages: Drop deprecated package sets #66301Strectch goals (I'm unlikely to do these myself)
- [ ] Package spacemacs- [ ] Package doom-emacsThese have proven to be difficult. See https://github.com/vlaci/nix-doom-emacs/.
The text was updated successfully, but these errors were encountered: