Re: File search
Hi Ludo, On Mon, 19 Dec 2022 at 22:25, Ludovic Courtès wrote: > I think at this point we could consider integration in Guix proper, > under ‘guix/scripts’. For that we could dismiss commit history. > > That’ll entail extra work (d’oh!) such as fine-tuning, writing tests, > and writing a section for the manual. > > The other option, if you prefer, would be to keep it in a separate repo > as an extension that people can install. To me that would be more of a > temporary solution because I think it’s a useful feature that ought to > be provided by Guix proper eventually. For what it is worth, I think it would better to reduce the number of scripts and instead have something more modular with extensions. The tradeoff about the maintenance cost is to not clear, I agree. On the other hand, reducing the number of modules that “guix pull” processes would help for improving the performance. For instance, let say that I am not interested by “guix system” and the computation of the derivation at “guix pull” time is not nothing. Another instance is all the plumbing commands. The manual would cover the extensions but it would be an opt-in choice by the user to install them. And it would reduce the load at “guix pull” time. My 2 cents. :-) Cheers, simon
Re: Release progress, week 10
Hi, zimoun skribis: > On Sun, 18 Dec 2022 at 16:13, Ludovic Courtès wrote: > >> I wrote a couple of paragraphs about this and other things yesterday >> (tried to keep it relatively short). Let me know if you think >> anything’s missing. > > All appears to me good. You do not mention that the coverage for > git-fetch is about ~98% and that Disarchive is very important because > the main source of origins is url-fetch, hence the total of 75%. > > I would add at the end of the first paragraph something like: > > [...] > Software Heritage as a fallback, with version 1.4.0 **the source code of > Guix channels is automatically fetched from Software Heritage** if its > original URL has become unreachable. As of the “[Preservation of Guix > Report](https://ngyro.com/pog-reports/latest/)” published in January > 2022, more than 98% of the packages directly referring to Git > repositories are now fully archived in Software Heritage. Sorry this came in too late, but we can have it in the announcement for hpc.guix.info (tomorrow I guess?). Thanks, Ludo’.
Re: Drafting a Guix blog post on the FHS container
Hi Jim, Jim Newsome skribis: > Anyways just thought I'd mention that I recently learned about this > feature, and was able to use it to get a downloaded [Tor Browser > Bundle] running with: That’s another good example, thanks for sharing! It’s especially interesting because the Tor project vets the binaries they provide. Ludo’.
Re: File search
Hi Antoine!
"Antoine R. Dumont (@ardumont)"
skribis:
> Here is the rough changelog:
>
> - The local db cache is now versioned. Migration will transparently
> happen for users at each index command calls (if need be).
Perfect!
> - The cli parsing got rewritten to be more flexible (inspired from
> existing code from guix, notably `guix home`).
>
> - We can now choose the indexation method using the
> `--with-method={store|manifests}` flag. The "manifests" method is the
> default, seel the help message for more details).
Excellent. (I think we can call it ‘--method’, without “with”.)
> - Finally, the indexation methods are displayed using a progress bar.
Yay, I love progress bars. :-)
> Heads up, I did not yet address the "output" part. Thanks @zimoun for
> the clarification btw ;)
Future work. ;-)
>> In the package case, the number of packages is known ahead.
>
> @civodul For the index 'store' implementation, ^ I did not find that
> information.
(length (all-packages)) gives you the total number of packages you’re
going to traverse. ‘all-packages’ is not instantaneous, but as a good
approximation the time spent in ‘all-packages’ can be ignored.
> So, as a costly implementation detail, I'm folding over all packages
> first to know the total number of packages (for the progress bar). And
> then another round trip to actually do the insert.
You could build up the package list just once and call ‘length’ on it.
> Hope you'll find it mostly to your taste!
I do!
> Note: I gather we'll rework the commits at some point (when it's ready)
> so I did not bother too much right now.
I think at this point we could consider integration in Guix proper,
under ‘guix/scripts’. For that we could dismiss commit history.
That’ll entail extra work (d’oh!) such as fine-tuning, writing tests,
and writing a section for the manual.
The other option, if you prefer, would be to keep it in a separate repo
as an extension that people can install. To me that would be more of a
temporary solution because I think it’s a useful feature that ought to
be provided by Guix proper eventually.
WDYT? :-)
Ludo’.
Re: Experimenting with reduced gcc-lib
Hi!
Julien Lepiller skribis:
> Le 15 décembre 2022 15:34:02 GMT+01:00, "Ludovic Courtès" a
> écrit :
>>> (outputs '("out";commands, etc. (60+ MiB)
>>> - "lib";libgcc_s, libgomp, etc. (15+
>>> MiB)
>>> + "shared-lib" ;libgcc_s, libgomp, etc. (5+
>>> MiB)
>>> + "static-lib" ;object code libraries and
>>> internal data files of GCC. (10+ MiB)
>>
>>The convention is to use “lib” for shared libraries and “static” for
>>static libraries.
>
> But using lib introduces a --libdir argument which is used to install static
> libs…
I see. Then maybe we should override the ‘configure’ phase, or repeat
‘--libdir’ in the hope that the second one wins?
>>Is libgomp in “lib”? Is it found when linking with ‘-fopenmp’?
>
> Well, shared-lib should be renaimed into libgcc, because it's the only
> library there.
OK.
> Libgomp amd all other libs are in static-lib (which is not well named either
> ^^'). It will be found I think but not tested (it find libstdc++ in the same
> directory).
Heh. :-)
I think it would be great to have all the .a in a separate output.
Thanks,
Ludo’.
Re: GMP GCC C++ Hurd cross-build failure on core-updates
Hi zamfofex,
And sorry for the late reply…
zamfofex skribis:
> hurdauth.c:166:1: error: conflicting types for ‘_S_msg_del_auth’; have
> ‘kern_return_t(mach_port_t, task_t, const int *, mach_msg_type_number_t,
> const int *, mach_msg_type_number_t)’ {aka ‘int(long unsigned int, long
> unsigned int, const int *, unsigned int, const int *, unsigned int)’}
> 166 | _S_msg_del_auth (mach_port_t me,
> | ^~~
> In file included from hurdauth.c:19:
> /tmp/guix-build-glibc-cross-i586-pc-gnu-2.35.drv-0/build/hurd/hurd/msg_server.h:72:15:
> note: previous declaration of ‘_S_msg_del_auth’ with type
> ‘kern_return_t(mach_port_t, mach_port_t, int *, mach_msg_type_number_t,
> int *, mach_msg_type_number_t)’ {aka ‘int(long unsigned int, long unsigned
> int, int *, unsigned int, int *, unsigned int)’}
>72 | kern_return_t _S_msg_del_auth
> | ^~~
> make[2]: *** [../o-iterator.mk:9:
> /tmp/guix-build-glibc-cross-i586-pc-gnu-2.35.drv-0/build/hurd/hurdauth.o]
> Error 1
Looking at this, glibc now has ‘const’ qualifiers for the ‘uids’ and
‘gids’ parameters:
--8<---cut here---start->8---
kern_return_t
_S_msg_del_auth (mach_port_t me,
task_t task,
const_intarray_t uids, mach_msg_type_number_t nuids,
const_intarray_t gids, mach_msg_type_number_t ngids)
--8<---cut here---end--->8---
This comes from this glibc commit:
commit 0eb230ccceee70c4b5d2a75807d2189aa4ed6e7c
Date: Sun Jan 16 18:28:40 2022 +
hurd: Make RPC input array parameters const
This follows mig's cf4bcc3f1435 ("Also add const qualifiers on server
side")
My guess is that you’re running a version of MiG that’s older than
cf4bcc3f1435 (MiG commit), and thus it generates stubs (such as the
‘msg_server.h’ file mentioned in the error message above) that lack
those ‘const’ qualifiers.
If that reasoning is good, updating MiG should fix it.
HTH,
Ludo’.
Re: guix package path
Hi,
On Mon, 19 Dec 2022 at 13:06, Antonio Carlos Padoan Junior
wrote:
> ~$ guix show -L /home/antonio/git/my-guix sbcl-lispiec
> guix show: error: sbcl-lispiec: package not found
>
> ~$ guix build -L /home/antonio/git/my-guix sbcl-lispiec
> guix build: error: sbcl-lispiec: unknown package
The issue is this snippet:
--8<---cut here---start->8---
(define-public gtklp
(let ((toolchain (specification->package "clang-toolchain@10")))
(package-with-c-toolchain gtklp-bad-tool `(("toolchain" ,toolchain)
--8<---cut here---end--->8---
and to be precise, it seems ’specification->package’. If it is removed,
and for example, adding #:use-module (gnu packages llvm) and
--8<---cut here---start->8---
(define-public gtklp
(let ((toolchain clang-toolchain-10))
(package
(inherit
(package-with-c-toolchain gtklp-bad-tool `(("toolchain" ,toolchain
(name "gtklp-with-clang"
--8<---cut here---end--->8---
Then all seems to work. Therefore, the same should fix
GUIX_PACKAGE_PATH.
Well, I do not know why it does not work as expected. Maybe an issue
with Guile modules and compilation.
Back to your original issue. Using
26f397ee26c2da6961a2ef893270ea03986ee55e from master and the channels
file:
--8<---cut here---start->8---
$ cat channels.scm
(list (channel
(name 'guix)
(url "https://git.savannah.gnu.org/git/guix.git;)
(branch "master")
(commit
"c8316c1e47ce2ace5474cbcda03555cf915b4fce"))
(channel
(name 'mine)
(url "file:///tmp/my-guix")
(branch "master")))
$ guix time-machine -C /tmp/channels.scm -- build sbcl-lispiec
/gnu/store/giwpdx5kcwfry3bx2yc90084nkmx7283-sbcl-lispiec-1.0.2
--8<---cut here---end--->8---
And note that,
--8<---cut here---start->8---
$ guix repl -q -L /tmp/my-guix
GNU Guile 3.0.8
Copyright (C) 1995-2021 Free Software Foundation, Inc.
Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.
Enter `,help' for help.
scheme@(guix-user)> ,use(guix)
scheme@(guix-user)> ,use(my-packages extra)
scheme@(guix-user)> ,build sbcl-lispiec
$1 = "/gnu/store/giwpdx5kcwfry3bx2yc90084nkmx7283-sbcl-lispiec-1.0.2"
scheme@(guix-user)>
--8<---cut here---end--->8---
Cheers,
simon
GNU Guix 1.4.0 released
We are pleased to announce the release of GNU Guix 1.4.0! This release corresponds to more than 28,000 commits over 18 months by 453 people. It adds new tools such as ‘guix shell’ for environment management and ‘guix home’, which lets you declare your home environment. It refines the user and packager experience and improves performance. This release also includes many new packages and services along bug fixes—see below for a list of changes. Read more about today’s announcement at: https://guix.gnu.org/en/blog/2022/gnu-guix-1.4.0-released/ • About GNU Guix is a transactional package manager and an advanced distribution of the GNU system that respects user freedom. Guix can be used on top of any system running the Hurd or the Linux kernel, or it can be used as a standalone operating system distribution for i686, x86_64, ARMv7, AArch64, and POWER9 machines. In addition to standard package management features, Guix supports transactional upgrades and roll-backs, unprivileged package management, per-user profiles, and garbage collection. When used as a standalone GNU/Linux distribution, Guix offers a declarative, stateless approach to operating system configuration management. Guix is highly customizable and hackable through Guile programming interfaces and extensions to the Scheme language. https://guix.gnu.org • Download Here are the compressed sources and a GPG detached signature[*]: https://ftp.gnu.org/gnu/guix/guix-1.4.0.tar.gz (39MB) https://ftp.gnu.org/gnu/guix/guix-1.4.0.tar.gz.sig Here are the bootable USB installation images and their signatures[*]: https://ftp.gnu.org/gnu/guix/guix-system-install-1.4.0.i686-linux.iso (778MB) https://ftp.gnu.org/gnu/guix/guix-system-install-1.4.0.i686-linux.iso.sig https://ftp.gnu.org/gnu/guix/guix-system-install-1.4.0.x86_64-linux.iso (814MB) https://ftp.gnu.org/gnu/guix/guix-system-install-1.4.0.x86_64-linux.iso.sig Here is the QCOW2 virtual machine (VM) image and its signature[*]: https://ftp.gnu.org/gnu/guix/guix-system-vm-image-1.4.0.x86_64-linux.qcow2 (1.2GB) https://ftp.gnu.org/gnu/guix/guix-system-vm-image-1.4.0.x86_64-linux.qcow2.sig Here are the binary tarballs and their signatures[*]: https://ftp.gnu.org/gnu/guix/guix-binary-1.4.0.aarch64-linux.tar.xz (94MB) https://ftp.gnu.org/gnu/guix/guix-binary-1.4.0.aarch64-linux.tar.xz.sig https://ftp.gnu.org/gnu/guix/guix-binary-1.4.0.armhf-linux.tar.xz (92MB) https://ftp.gnu.org/gnu/guix/guix-binary-1.4.0.armhf-linux.tar.xz.sig https://ftp.gnu.org/gnu/guix/guix-binary-1.4.0.i686-linux.tar.xz (98MB) https://ftp.gnu.org/gnu/guix/guix-binary-1.4.0.i686-linux.tar.xz.sig https://ftp.gnu.org/gnu/guix/guix-binary-1.4.0.powerpc64le-linux.tar.xz (98MB) https://ftp.gnu.org/gnu/guix/guix-binary-1.4.0.powerpc64le-linux.tar.xz.sig https://ftp.gnu.org/gnu/guix/guix-binary-1.4.0.x86_64-linux.tar.xz (98MB) https://ftp.gnu.org/gnu/guix/guix-binary-1.4.0.x86_64-linux.tar.xz.sig Use a mirror for higher download bandwidth: https://www.gnu.org/order/ftp.html Here are the SHA256 hashes: 43c769cbf632ef05449ac1fa48c1ba152c33494c6abc7e47137bba7b2149f8a4 guix-1.4.0.tar.gz 72d807392889919940b7ec9632c45a259555e6b0942ea7bfd131101e08ebfcf4 guix-binary-1.4.0.aarch64-linux.tar.xz 162c114ffcd5d331ec4c2974fcdca09e601e0e62950925a1d839584a7c720130 guix-binary-1.4.0.armhf-linux.tar.xz 1e6124e917288097ef94eebd175bf1bc73f5be67a20e98fec7d33368050fd02d guix-binary-1.4.0.i686-linux.tar.xz a0c54a0af8b0ae3097bfd33ddf408503a5df2d98b0848a83bb7e8da5c8d1a7fa guix-binary-1.4.0.powerpc64le-linux.tar.xz 236ca7c9c5958b1f396c2924fcc5bc9d6fdebcb1b4cf3c7c6d46d4bf660ed9c9 guix-binary-1.4.0.x86_64-linux.tar.xz 07a5484d5c8f11294fabe0d32b422bdfd966ed9d8faf396cbedd0b6e3c39c740 guix-system-install-1.4.0.i686-linux.iso 087a97dba2319477185471a28812949cc165e60e58863403e4a606c1baa05f81 guix-system-install-1.4.0.x86_64-linux.iso 905dbdf0d32490eda66c4afdba98a80d0c3e50358b1a868423771af0a8561cae guix-system-vm-image-1.4.0.x86_64-linux.qcow2 [*] Use a .sig file to verify that the corresponding file (without the .sig suffix) is intact. First, be sure to download both the .sig file and the corresponding tarball. Then, run a command like this: gpg --verify guix-1.4.0.tar.gz.sig If that command fails because you don't have the required public key, then run this command to import it: gpg --keyserver keys.openpgp.org \ --recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 and rerun the ‘gpg --verify’ command. • Changes in 1.4.0 (since 1.3.0) ** Package management *** New ‘guix home’ command, for home environment management *** New ‘guix shell’ command, the successor to ‘guix environment’ *** New ‘guix system edit’ command, to edit services *** New ‘deb’ format for the ‘guix pack’ command *** New ‘guix import minetest’ command, to import Minetest
Re: guix package path
Hi, thanks a lot for your help! zimoun writes: > > This package sbcl-lispiec is indeed not in: > > https://gitlab.com/acpadoanjr/my-guix.git/ > > and there no line 217 inside the file: > > https://gitlab.com/acpadoanjr/my-guix/-/blob/main/my-packages/extra.scm > > Therefore, I guess something is twisted somewhere. Sorry, I forgot to mention that the channel is not on main branch, but on master branch. > > Could you try: > > guix show -L /home/antonio/git/my-guix sbcl-lispiec > guix build -L /home/antonio/git/my-guix sbcl-lispiec > > > Cheers, > simon I got bad returns: ~$ guix show -L /home/antonio/git/my-guix sbcl-lispiec guix show: error: sbcl-lispiec: package not found ~$ guix build -L /home/antonio/git/my-guix sbcl-lispiec guix build: error: sbcl-lispiec: unknown package while guix search is still working: ~$ guix search sbcl-lispiec name: sbcl-lispiec version: 1.0.2 outputs: + out: everything systems: x86_64-linux i686-linux dependencies: libiec61850@v1.5.0 sbcl-alexandria@1.4 sbcl-bordeaux-threads@0.8.8 sbcl-cffi-c-ref@1.0-0.8123cbb sbcl-cffi@0.24.1 sbcl-cl-csv@1.0.6-2.68ecb5d sbcl-cl-ppcre@2.1.1 sbcl-cl-utilities@0.0.0-1.dce2d2f + sbcl-croatoan@0.0.1-5.5d0949d sbcl-deeds@1.1.1-1.f5df54e sbcl-iterate@1.5.3 sbcl-slynk@1.0.43-6.4513c38 location: my-packages/extra.scm:217:4 homepage: https://gitlab.com/acpadoanjr/lispiec.git license: GPL 3+ synopsis: IEC-61850 common-lisp library. description: IEC-61850 common-lisp library for simulation based on cffi and libiec61850. relevance: 20 Best regards, -- Antonio Carlos PADOAN JUNIOR GPG fingerprint: 243F 237F 2DD3 4DCA 4EA3 1341 2481 90F9 B421 A6C9
Re: GMP GCC C++ Hurd cross-build failure on core-updates
On Thu, 2022-12-15 at 12:17 +0100, Svante Signell wrote:
>
> Hi,
>
> The problem is probably that you need to add --enable-add-ons=libpthread to
> configure when building first version of cross-glibc. This is to obtain weak
> references when building libcstd++ of cross-gcc:
>
> nm --dynamic /cross-tools/lib/libstdc++.so.6.0.30|grep pthread
> ...
> w __pthread_key_create
> w pthread_key_create
> w pthread_key_delete
I've been looking into this problem a little further: You need the attached
patch: libstdc++-hurd.diff, at least for gcc-11 and gcc-12 (and probably gcc-13
too)
Good luck!
This is notably needed because in glibc 2.34, the move of pthread functions
into libc.so happened for Linux only, not GNU/Hurd.
The pthread_self() function can also always be used fine as it is on
GNU/Hurd.
libstdc++-v3/ChangeLog:
* config/os/gnu-linux/os_defines.h [!__linux__]
(_GLIBCXX_NATIVE_THREAD_ID, _GLIBCXX_GTHREAD_USE_WEAK): Do not define.
--- a/libstdc++-v3/config/os/gnu-linux/os_defines.h
+++ b/libstdc++-v3/config/os/gnu-linux/os_defines.h
@@ -49,22 +49,24 @@
// version dynamically in case it has changed since libstdc++ was configured.
#define _GLIBCXX_NO_OBSOLETE_ISINF_ISNAN_DYNAMIC __GLIBC_PREREQ(2,23)
-#if __GLIBC_PREREQ(2, 27)
-// Since glibc 2.27 pthread_self() is usable without linking to libpthread.
-# define _GLIBCXX_NATIVE_THREAD_ID pthread_self()
-#else
+#ifdef __linux__
+# if __GLIBC_PREREQ(2, 27)
+// Since glibc 2.27 Linux' pthread_self() is usable without linking to libpthread.
+# define _GLIBCXX_NATIVE_THREAD_ID pthread_self()
+# else
// Before then it was in libc.so.6 but not libc.a, and always returns 0,
// which breaks the invariant this_thread::get_id() != thread::id{}.
// So only use it if we know the libpthread version is available.
// Otherwise use (__gthread_t)1 as the ID of the main (and only) thread.
-# define _GLIBCXX_NATIVE_THREAD_ID \
- (__gthread_active_p() ? __gthread_self() : (__gthread_t)1)
-#endif
+# define _GLIBCXX_NATIVE_THREAD_ID \
+ (__gthread_active_p() ? __gthread_self() : (__gthread_t)1)
+# endif
-#if __GLIBC_PREREQ(2, 34)
-// Since glibc 2.34 all pthreads functions are usable without linking to
+# if __GLIBC_PREREQ(2, 34)
+// Since glibc 2.34 all Linux pthreads functions are usable without linking to
// libpthread.
-# define _GLIBCXX_GTHREAD_USE_WEAK 0
+# define _GLIBCXX_GTHREAD_USE_WEAK 0
+# endif
#endif
#endif
Re: guix package path
Hi, On Mon, 19 Dec 2022 at 08:12, Antonio Carlos Padoan Junior wrote: > This channel is also available here > https://gitlab.com/acpadoanjr/my-guix.git/ > But I want to use it from my local machine while I'm developing. > > Using the GUIX_PACKAGE_PATH, I have a local package (sbcl-lispiec) that seems > correctly loaded: > > > ~$ guix search sbcl-lispiec [...] > location: /home/antonio/git/my-guix/my-packages/extra.scm:217:4 [...] > > > But I cannot build it or install it: > > > ~$ guix build sbcl-lispiec > guix build: error: sbcl-lispiec: unknown package > This package sbcl-lispiec is indeed not in: https://gitlab.com/acpadoanjr/my-guix.git/ and there no line 217 inside the file: https://gitlab.com/acpadoanjr/my-guix/-/blob/main/my-packages/extra.scm Therefore, I guess something is twisted somewhere. Could you try: guix show -L /home/antonio/git/my-guix sbcl-lispiec guix build -L /home/antonio/git/my-guix sbcl-lispiec Cheers, simon
Re: Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm
Hi, On Sun, 18 Dec 2022 at 01:54, Mekeor Melire wrote: > What do you think? Should this go into a separate, private > channel? Into the Guix Cookbook? Into Guix, if so, then probably > with lots of changes? Should it just stay here, in this mailing > list thread? Or do you think this is just a bad idea in general? >From my point of view, you could convert to an extension, say “guix emacs” and share this extension as a regular Guix packages. This would help to iterate and discuss various implementation details using concrete and easy tests. Cheers, simon
Re: Release progress, week 10
Hi, On Sun, 18 Dec 2022 at 16:13, Ludovic Courtès wrote: > I wrote a couple of paragraphs about this and other things yesterday > (tried to keep it relatively short). Let me know if you think > anything’s missing. All appears to me good. You do not mention that the coverage for git-fetch is about ~98% and that Disarchive is very important because the main source of origins is url-fetch, hence the total of 75%. I would add at the end of the first paragraph something like: --8<---cut here---start->8--- [...] Software Heritage as a fallback, with version 1.4.0 **the source code of Guix channels is automatically fetched from Software Heritage** if its original URL has become unreachable. As of the “[Preservation of Guix Report](https://ngyro.com/pog-reports/latest/)” published in January 2022, more than 98% of the packages directly referring to Git repositories are now fully archived in Software Heritage. --8<---cut here---end--->8--- >> I still think that it would be worth to mention the removal of many >> Python 2 packages and that the project stops to maintain Python 2 >> packages. I know it appears in NEWS but it costs nothing to restate >> because many people are not reading all the details of all. :-) > > Oh right, I’ll add a few lines. LGTM. Cheers, simon PS: A side note and it is too late. :-) This: - [“Using TeX and LaTeX”](https://guix.gnu.org/manual/en/html_node/Using-TeX-and-LaTeX.html) appears to me a Cookbook section and not a Manual section. Well, let discuss that on January. :-)
Re: Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm
On 2022-12-18 09:11, Liliana Marie Prikler wrote: > Am Sonntag, dem 18.12.2022 um 01:54 + schrieb Mekeor Melire: >> Nevertheless, for me, personally, it's pretty neat and handy to >> use, because I don't need to maintain the list of emacs-packages >> in two places. I also think that it could come pretty handy for >> many others, at least in order to initialize their user-profile, >> by running something like ~guix package -e '(some-magic >> "/home/user/.emacs.d/init.el")'~. > I think we should be able to build an Emacs service in Guix Home that > can manage init.el. As a workaround, use-package should also have a > :when clause, so you can use :when (featurep 'some-package-autoloads) > if you're unsure whether 'some-package is actually installed. This > makes your init file a little more resilient and is particularly useful > with pure shells. > >> What do you think? Should this go into a separate, private >> channel? Into the Guix Cookbook? Into Guix, if so, then probably >> with lots of changes? Should it just stay here, in this mailing >> list thread? Or do you think this is just a bad idea in general? > Given the caveats, I would rather like to see an Emacs Lisp based > script that mocks use-package and generates a manifest by evaluting > init.el. This should give you more correct results. It's not a bad > idea per se, but as-is, I think it would better be maintained in your > own channel before upstreaming. > > For upstreaming, I see two potential paths. The first one would be > integration to `guix home import', which Andrew Tropin (CC'd) could > probably tell you more on. I'm neither the author, nor the user of guix home import, however I think it could be a good place for such a functionality, but I would suggest to maintain this helper functions for a while in a personal channel, mature it and revisit this question later. To make a solution more robust and complete, you can take a look at straight.el and how it redefines use-package-ensure-function and do something similiar to generate a list of packages for guix. Another detail is that use-package accepts a symbol value for :ensure and you can write something like: --8<---cut here---start->8--- ;; (setq use-package-always-ensure t) ; as an alternative to :ensure t (use-package vertico :ensure t ...) (use-package vertico-directory :ensure vertico ...) --8<---cut here---end--->8--- This way you won't need a concept of "blocked" packages. One more idea: make a function which accepts file-like/origin object instead of string and generates a package with propagated-dependencies based on the content of source code provided as an argument. Personally, with my emacs config I do the things vice versa: I have elisp code in scheme files with a list of explicit dependencies: https://git.sr.ht/~abcdw/rde/tree/b57387f2/src/rde/features/emacs-xyz.scm#L946 Nevertheless, your idea with use-package looks good to me. > The second would be integration into `guix package' as a callable > function/command line argument, but IMHO that's less likely to pass. > > > Cheers -- Best regards, Andrew Tropin signature.asc Description: PGP signature
