<
multun>
If any of you has the time and will to have a look, it would be awesome
<
multun>
I also try to debug this by myself, eventhough I would need a few hints :)
<
adisbladis>
multun: I tried looking at it but I don't know :/
<
adisbladis>
I'm tempted to pin an older known-working version
<
adisbladis>
multun: It is possible to use the one from melpa stable in the mean time if that works for you
<
adisbladis>
emacsPackagesNg.melpaStablePackages.irony
<
adisbladis>
Argh, even that doesn't work :/
<
adisbladis>
Another build failure
<
iqubic>
Why are there so many build failures?
<
etu>
Because emacs packages are more than elisp files
<
etu>
elisp files are easy
<
iqubic>
I managed to fix my "home-manager switch" issues from earlier.
<
adisbladis>
99% of all pure-elisp packages "just works"
<
adisbladis>
It's the other ones that are problematic
<
adisbladis>
We have a few thousands emacs packages and only a handful ever fail
<
adisbladis>
Irony is one of those things with a lot of moving parts
<
iqubic>
Auctex is another with moving parts.
<
iqubic>
Which is one that I want to install. So
<
iqubic>
I'll have to look into that myself.
<
iqubic>
Also, I'm now compile emacs on my machine.
* etu
fixed the emacsql thingy, that a lot of things depends on :)
<
iqubic>
auctex is just a big pile of difficulty.
<
etu>
adisbladis: I'm reviewing your PR now, but I'm in a world of pain on a really slow wifi that probably uses internet from space :)
<
iqubic>
Has the extraPackages option been added to the overlay yet?
<
adisbladis>
etu: Nice, space internet
<
etu>
yes, with extra latency and all
<
adisbladis>
iqubic: Nope, fromEmacsUsePackage has not been added yet
<
adisbladis>
I can do that today. I have a few hours to kill.
<
iqubic>
I thought etu added an extra optional argument to make it so that you can add packages that don't have a corresponding use-package section.
<
adisbladis>
etu: Mainly it's the bit about backwards compatible aliases I'd like an opinion on.
<
iqubic>
Or was I wrong about that?
<
adisbladis>
iqubic: He did indeed but that hasn't reached the overlay yet
<
iqubic>
I think I might have a few uses for that. Not sure.
<
adisbladis>
Later today (:
<
iqubic>
thank you for your hard work on this.
<
iqubic>
I really appreciate all of this work.
<
etu>
adisbladis: I'm thinking of we should keep a emacsPackagesNg = emacsPackages; or something to not break for existing users of emacsPackagesNg
<
etu>
I'm all for starting to use emacsPackages as the "main goto place", but to have a copy of it for 19.09 and then remove that reference for 20.03
<
iqubic>
And what are we going about `fromEmacsUsePackage'?
<
etu>
iqubic: That's not part of the PR to drop the legacy emacs packages
<
iqubic>
What is the purpose of emacsPackagesNg? And how does that differ from emacsPackages?
<
iqubic>
And are we eventually going to move all of this into main line Nixpkgs at some point?
<
iqubic>
I guess I'm just a little unclear about the long-term goals of this project.
<
{^_^}>
#66301 (by adisbladis, 1 week ago, open): emacs-packages: Drop deprecated package sets
<
etu>
That's the PR in question
<
etu>
emacsPackagesNg is what have been the goto place to get your emacs deps in nixpkgs since like many years now
<
etu>
and emacsPackages have still been around but very out of date
<
iqubic>
And why are there two things that are essentially the same?
<
etu>
The new one would replace the old one, but the old one isn't dropped yet, that's what that PR is aiming to do.
<
etu>
Also gotta love mosh, what an amazing software wrapper around ssh. I have 1.5s of delay and are typing away fine in this terminal :)
<
iqubic>
What makes it difficult to just upgrade the new package set?
<
etu>
emacsPackagesNg has already been replaced recently
<
iqubic>
So why hasn't this PR been merged?
<
etu>
And that caused some breackage
<
etu>
Because it replaces the old one that people may still rely on
<
etu>
and it behaves differently
<
iqubic>
Ah. I see.
<
adisbladis>
I still want to add installing the configuration in the closure
<
adisbladis>
I changed extraEmacsPackages a bit too, it's now a function
<
adisbladis>
Which makes it possible to pick which attrset you want to take a package from without combining it with overrides
<
adisbladis>
etu:: iqubic ^
iqubic has quit [Remote host closed the connection]
<
multun>
is there a way to use an overlay to modify emacs packages ?
<
etu>
adisbladis: awesome, I see you took some of my ideas :)
iqubic has joined #nixos-emacs
<
multun>
I'm so confused
<
multun>
nix-shell --pure -E "(with import <nixpkgs> {}; emacsWithPackages (p: p.irony)).deps.explicitRequires"
<
multun>
this doesn't yield the Wrong type argument: arrayp, nil error
<
multun>
it fails at a much later stage
<
multun>
$ du -b /tmp/irony_*.tar
<
multun>
1392640 /tmp/irony_failing.tar
<
multun>
1843200 /tmp/irony_working.tar
<
multun>
so for some reason, the build doesn't have the same output and the emacs script then fails to understand the tar file
<
multun>
adisbladis: that's because the version string has a dot in it
<
multun>
it makes something go mad, somewhere
iqubic has quit [Remote host closed the connection]