Hi Adam, Am Donnerstag, dem 27.06.2024 um 08:57 -0500 schrieb Adam Porter: > Thanks. > > If I may ask here, as it seems relevant and might help other users in > the future: > > A few minutes ago I ran "guix pull", but after it finished, "guix > show emacs" still shows: > > name: emacs > version: 29.3 > > Am I missing something? e.g. the equivalents in Debian, like "apt > show emacs" or "apt policy emacs", show both installed and available > versions. You're missing the graft, which apparently does not show up in "guix show".
> So as a user, how am I to know whether I'm using the latest version > of a package? I also tried "guix upgrade -n" (which updates > substitute lists from the network, which can significantly delay its > finishing for a simple check like this), and it shows: > > The following packages would be upgraded: > emacs (dependencies or package changed) > > But maybe that's affected by the workaround I'm using (see below). FWIW, with emacs you can check (emacs-version). More generally, this is a bug – replacements ought to be announced somehow. > > > FWIW, I had hoped that I could install it by running: > > > > > > guix install --with-version=emacs=29.4 emacs > > > > > > But that fails the validate-comp-integrity phase, showing that > > > all of > > > its tests fail, with every function being loaded in byte-compiled > > > form instead of native-compiled. > > > Ah, yes, that is not something you can do with --with-version, as > > it > > disregards our patches and everything. > > Ah, I wish I had known that. FWIW, looking at > < > https://guix.gnu.org/manual/en/html_node/Package-Transformation-Option > s.html>, I can't even find "--with-version" documented at all. But > besides that, none of them seem to explain that such options may > discard parts of the package definition, such as patches (if any of > those other options do--is it only "--with-version" that does?). > Does a documentation bug need to be filed about this? The info manual (which you can read locally) has both, as well as the warning you seek. > > As for how to work around this, you can do a more elaborate package > > definition: > > > > (package > > (inherit emacs) > > (version NEW_VERSION) > > (source (origin (inherit (package-source emacs)) > > (uri NEW_URI)))) > > > > This should automatically apply our patches. Or, you can locally > > run `guix refresh -u emacs'. > > Thanks for the pointer. I defined a package called "emacs-jit" (and > a corresponding "emacs-minimal-jit") that comments out the > JIT-disabling patches, so that I can still JIT-compile packages > installed through Emacs, and it seems to be working fine. > > Would you be willing to accept some kind of package definition like > that being added to Guix, as an alternative to the main "emacs" > package? (I won't quibble over the name.) I think that there are a > significant number of users who would like to use Guix to keep Emacs > up-to-date without sacrificing the ability to native-compile packages > installed from within Emacs. It would be nice to have this in Guix > so that I wouldn't have to manually update the package definition > according to upstream changes. But then you'd be shifting the maintenance burden to us Guix. We already have enough Emacs variants to keep track of as-is, and adding yet another orthogonal angle is not going to scale well. Plus, for this variant you'd lose all the benefits that Guix provides – I don't see this as a reasonable thing to ship, to be honest. Cheers
