Re: Mechanism for helping in multi-channels configuration (and Xapian index)

2024-05-06 Thread Simon Tournier
Hi, Sorry for the long delay. On lun., 18 mars 2024 at 16:05, Christina O'Donnell wrote: >> 2: https://issues.guix.gnu.org/issue/39258 > As I said above, [2] is a fairly long thread, but I think I get the > general idea. It seems that Xapian was implemented but didn't have the > desired

Re: Mechanism for helping in multi-channels configuration (and Xapian index)

2024-03-18 Thread Christina O'Donnell
Hi Simon, Sorry for the really long delay, I meant to reply after I'd had a good read through the conversation you linked, but I haven't had a chance to really get into it yet, but I have read enough to get a surface idea of the project. The project looks fun, and looks like it will help Guix

Re: Mechanism for helping in multi-channels configuration

2024-03-12 Thread Attila Lendvai
> Although I concur with this need, I do not see how it would be help for > detecting compatibility between channels. :-) maybe i'm overthinking this, and all we need is a way to point to git commit ranges that are compatible. more specifically, i'm maintaining the guix-crypto channel, and i

Re: Mechanism for helping in multi-channels configuration

2024-02-15 Thread Simon Tournier
Hi Attila, On mar., 06 févr. 2024 at 17:16, Attila Lendvai wrote: >> The wishlist is: provide a machine-readable description on guix-science >> channel side in order to help in finding the good overlap between >> commits of different channels. > > i wrote about a missing abstraction here: > >

Re: Mechanism for helping in multi-channels configuration

2024-02-15 Thread Simon Tournier
Hi Christina, On sam., 03 févr. 2024 at 15:27, Christina O'Donnell wrote: >  1. Have a script that scrapes all the define-public symbols in every > file in >     every package. I think you mean ’fold-packages’. >  2. Have a script that determines the symbols needed by each file. (Macros >

Re: Mechanism for helping in multi-channels configuration

2024-02-06 Thread Attila Lendvai
> The wishlist is: provide a machine-readable description on guix-science > channel side in order to help in finding the good overlap between > commits of different channels. i wrote about a missing abstraction here: https://lists.gnu.org/archive/html/guix-devel/2023-12/msg00104.html which is

Re: Mechanism for helping in multi-channels configuration

2024-02-06 Thread Attila Lendvai
> Anything is better than an obscure failure/backtrace i disagree with this specific statement. in the long run, the (inconspicuous) cost of added complexity can easily move anything into net negative territory. IOW, feel encouraged to account for the cost of complexity. it's rarely done

Re: Mechanism for helping in multi-channels configuration

2024-02-06 Thread Maxim Cournoyer
Hi, Simon Tournier writes: > Hi, > > Well, using Guix bdab356 from a little bit more than one month old, then > associating the channel guix-science 0b3d4a2f last week, I get the > failure: > > $ guix build /gnu/store/g3aa5rh7bs5pyxd3q1gvhwz1s9z1vh3z-guix-science.drv > The following derivation

Re: Mechanism for helping in multi-channels configuration

2024-02-03 Thread Christina O'Donnell
Hi Simon, The wishlist is: provide a machine-readable description on guix-science channel side in order to help in finding the good overlap between commits of different channels. It could be nice if instead of an hard error, “guix pull” could say: « the channel ’guix’ needs to be at least at

Mechanism for helping in multi-channels configuration

2024-02-03 Thread Simon Tournier
Hi, Well, using Guix bdab356 from a little bit more than one month old, then associating the channel guix-science 0b3d4a2f last week, I get the failure: --8<---cut here---start->8--- $ guix build /gnu/store/g3aa5rh7bs5pyxd3q1gvhwz1s9z1vh3z-guix-science.drv The