lspce-module: 1.1.0-unstable-2024-07-14 -> 1.1.0-unstable-2024-08-04 #332629
Conversation
|
@jian-lin this is what I was talking about: just promote lspce-module as a regular package and let |
|
Is this draft ready for review? |
ofborg
bot
added
8.has: package (new)
AndersonTorres
force-pushed
the
upload-lspce-module
branch
2 times, most recently
from
b8ba292 to
e9cdf72
Compare
|
yes |
I do not think so.
Agreed. I will add some context. The motivation of this PR is to make users be able to override This PR provides one possible implementation. #329709 is another possible implementation. The code to override Note that there is yet another implementation: rewriting --- a/pkgs/applications/editors/emacs/elisp-packages/manual-packages/lspce/package.nix
+++ b/pkgs/applications/editors/emacs/elisp-packages/manual-packages/lspce/package.nix
@@ -8,12 +8,9 @@
yasnippet,
}:
-let
- lspce-module = callPackage ./module.nix { };
-in
-melpaBuild {
+melpaBuild (finalAttrs: {
pname = "lspce";
- inherit (lspce-module) version src meta;
+ inherit (finalAttrs.passthru.lspce-module) version src meta;
packageRequires = [
f
@@ -22,13 +19,13 @@ melpaBuild {
];
# to compile lspce.el, it needs lspce-module.so
- files = ''(:defaults "${lib.getLib lspce-module}/lib/lspce-module.*")'';
+ files = ''(:defaults "${lib.getLib finalAttrs.passthru.lspce-module}/lib/lspce-module.*")'';
passthru = {
- inherit lspce-module;
+ lspce-module = callPackage ./module.nix { };
updateScript = nix-update-script {
attrPath = "emacsPackages.lspce.lspce-module";
extraArgs = [ "--version=branch" ];
};
};
-}
+})The code to override emacs.pkgs.lspce.overrideAttrs (old: {
passthru = old.passthru // {
lspce-module = old.passthru.lspce-module.overrideAttrs {
version = ...;
src = ...;
...
};
};
})If --- a/pkgs/applications/editors/emacs/elisp-packages/manual-packages/lspce/package.nix
+++ b/pkgs/applications/editors/emacs/elisp-packages/manual-packages/lspce/package.nix
@@ -8,12 +8,9 @@
yasnippet,
}:
-let
- lspce-module = callPackage ./module.nix { };
-in
-melpaBuild {
+melpaBuild (finalAttrs: {
pname = "lspce";
- inherit (lspce-module) version src meta;
+ inherit (finalAttrs.lspce-module) version src meta;
packageRequires = [
f
@@ -22,13 +19,14 @@ melpaBuild {
];
# to compile lspce.el, it needs lspce-module.so
- files = ''(:defaults "${lib.getLib lspce-module}/lib/lspce-module.*")'';
+ files = ''(:defaults "${lib.getLib finalAttrs.lspce-module}/lib/lspce-module.*")'';
+
+ lspce-module = callPackage ./module.nix { };
passthru = {
- inherit lspce-module;
updateScript = nix-update-script {
attrPath = "emacsPackages.lspce.lspce-module";
extraArgs = [ "--version=branch" ];
};
};
-}
+})And the override code is simpler: emacs.pkgs.lspce.overrideAttrs (old: {
lspce-module = old.lspce-module.overrideAttrs {
version = ...;
src = ...;
...
};
}) |
AndersonTorres
force-pushed
the
upload-lspce-module
branch
from
e9cdf72 to
4c6f5fc
Compare
|
Migrated to emacsPackages. |
|
Anything else, @jian-lin @adisbladis ? |
|
A similar question: does |
|
In practical terms, it does not. The only package that really needs lspce-module is lspce-elisp itself. On the other hand:
"Not being useful outside lspce-elisp" does not look like a sufficient motivation to avoid the detachment. (Unfortunately I can't think about packages with the sole purpose of leveraging other single package; however I don' t believe they don't exist. Bootstrap seeds are a perfect example of this.) |
I am not convinced and I still think top-level packages should be useful on it own.
Why should it not be a mere implementation detail? Even as an implementation detail, i.e., non top-level, it can still be overridden. See #329709 (comment)
Being a package does not mean being a top-level package. I think
With this PR applied, code to override final: prev: {
lspce-module = prev.lspce-module.overrideAttrs { ... };
lspce = prev.lspce.overrideAttrs {
inherit (final.lspce-module) version src;
};
}An alternative PR #329709 does not treat final: prev: {
lspce = let lspce-module' = prev.lspce.lspce-module.overrideAttrs { ... }; in
(prev.lspce.override { lspce-module = lspce-module'; }).overrideAttrs (old: {
inherit (lspce-module') version src;
passthru = old.passthru // { lspce-module = lspce-module'; }; # optional
});
}To be honest, I do not think one code is easier than another. Both of them are not good because users have to know that I think the real issue is that currently different build helpers (
I do find an example supporting my opinion: vim-clap. |
Since there is a compelling reason to override lspce-module in emacsPackages.lspce, it makes sense to treat it as input parameter, rather than an implementation detail.
|
I was elaborating an answer, however it would not be satisfactory. My objection with your PR is, basically, two things:
The main problem is what you said, the builders are not composable. The examples you provided are not convincing, I should say.
rime = super.rime.overrideAttrs (old: {
buildInputs = (old.buildInputs or [ ]) ++ [ pkgs.librime ];
preBuild = (old.preBuild or "") +
(if pkgs.stdenv.isDarwin then
''
export MODULE_FILE_SUFFIX=".dylib"
make lib
mkdir -p /tmp/build/rime-lib
cp *.dylib /tmp/build/rime-lib
''
else
''
make lib
mkdir -p /build/rime-lib
cp *.so /build/rime-lib
'');
postInstall = (old.postInstall or "") +
(if pkgs.stdenv.isDarwin then
''
install -m444 -t $out/share/emacs/site-lisp/elpa/rime-* /tmp/build/rime-lib/*.dylib
''
else
''
install -m444 -t $out/share/emacs/site-lisp/elpa/rime-* /build/rime-lib/*.so
'');
});How should The best I can think in this situation is to inject |
It is ugly as hell, but at least it is overridable.
AndersonTorres
force-pushed
the
upload-lspce-module
branch
from
4c6f5fc to
4ba28ed
Compare
Why is
Create a normal manual elisp package and move what is now in Example{
melpaBuild,
fetchFromGitHub,
librime,
dash,
popup,
posframe,
}:
melpaBuild {
pname = "rime";
version = "1.0.5-unstable-2024-01-30";
src = fetchFromGitHub {
owner = "DogLooksGood";
repo = "emacs-rime";
rev = "d8c0a99b0282d3e0aca53146789f6864181228e7";
hash = "sha256-rx9SvIuMVL0Vt1uKbLhxbxTKyftdRp/BVj71hJIyQi4=";
};
packageRequires = [
dash
popup
posframe
];
buildInputs = [ librime ];
preBuild = ''
make lib
export RIME_LIB_DIR=$NIX_BUILD_TOP/rime-lib
mkdir -p $RIME_LIB_DIR
cp *.so $RIME_LIB_DIR
'';
postInstall = ''
install -m444 -t $out/share/emacs/site-lisp/elpa/rime-* $RIME_LIB_DIR/*.so
'';
ignoreCompilationError = false;
}
What is the point of this completely syntactic refactoring? I fail to see how it improves user experience for overriding. In this implementation, to override About composability, I find that with some modifications, the rust build helper does compose well with elisp build helpers. See the rewriting of |
It would be visible to |
Description of changes
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.