Re: How can we decrease the cognitive overhead for contributors?

[Ricardo Wurmus]

Vagrant Cascadian  writes:

> The only thing clunky about this particular aspect of the workflow
> described is the fact that the guix community (maintainers?) have
> decided on a one patch per mail policy with a cover letter, rather than
> submitting the patches as attachments in the initial mail.

You are right.  When I started contributing I actually did attach all
patches in one email.  I wonder why we stopped doing that.

I’ll say that many of my gripes with (the GNU instance of) Debbugs are
due to the fact that we can’t customize it to better suit our needs — it
is a shared resource with a complicated maintenance story.  So all
changes went into Mumi as crude workarounds.  I think this is a dead end
and we’d be better off leaving the shared GNU instance of Debbugs
behind.

-- 
Ricardo

CI job for lisp-team branch

[Guillaume Le Vaillant]

Hi.
I created a lisp-team branch to work one some updates for clisp and
sbcl. Could someone with admin access to the CI things add a job for it?
Thanks.


signature.asc
Description: PGP signature

Re: How can we decrease the cognitive overhead for contributors?

[Giovanni Biscuolo]

Hi,

Felix Lechner via "Development of GNU Guix and the GNU System
distribution."  writes:

> Hi all,
>
> On Sun, Sep 3, 2023 at 3:35 AM Ricardo Wurmus  wrote:
>>
>> I won’t contribute to Mumi any more.  Giving it up doesn’t hurt my
>> feelings.  I’d be glad to see it gone.
>
> For what it's worth, I like Mumi.

me too: it's a very good implementation of a web interface for an
email-based issue tracking (eco)system, in particular it's a very useful
implementation of a web based Xapian interface specialized in issue
_tracking_

> One day, I hope to help offer Scheme diffs there. Perhaps it will take
> just a pull from the base commit and guile-sexp-diff. [1]
>
> Maybe Git can eventually use such diffs, too. As a group we deserve
> better.

Git already have a mechanism to use external diff programs, via
.gitattributes; all we need are better/specialized/semantic diff
programs packaged in Guix

> I like the email-based workflow.

I'd say that an email-based workflow is a conditio sine qua non for
_all_ projects, possibly supplemented by a web based interface, possibly
better than Debbugs, possibly better than mumi

mumi have a _great_ potential to be extended, it could even be extended
to become the web/CLI frontend to other email-based issue tracking
systems

[...]

Happy hacking, Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: CI job for lisp-team branch

[宋文武]

Guillaume Le Vaillant  writes:

> Hi.
> I created a lisp-team branch to work one some updates for clisp and
> sbcl. Could someone with admin access to the CI things add a job for it?
> Thanks.

Hello, Curiass CI job created.

Thanks.

Re: How can we decrease the cognitive overhead for contributors?

[Attila Lendvai]

> To second this, I'd like to note for the record that on fedi at least
> 1-2 people told me that they chose Nix over Guix because they don't want
> to deal with the email based workflow. At least one of these people is
> a highly skilled programmer with decades of experience.


FWIW,

i'm 46, programming since my childhood. i have 10+ years of Common Lisp 
experience using Emacs, most of it on opensource projects.

here's an approximate list of what's consuming/training my 
frustration-tolerance with Guix:

 - debbugs and related tooling. i could live with an email based
   workflow, but whatever is documented, or at least whatever i have
   put together locally, is very inefficient. the chore vs. coding
   ratio is low.

 - large backlog. contributions somtimes even fall through the cracks.

 - strict adherence to changelog style commit messages without a
   clearly worded and documented argument about why it's worth the
   effort in 2023. whenever 'C' fails to add an entry to the commit
   message in Emacs, i groan out loud.

i came to Guix from a couple of years of NixOS (also contributing), being 
frustrated by the way they use Nix, the language, to describe OS services. it 
felt an uphill battle for no good reason that Guix liberated. Guix has much 
more flexibility and common sense in the coding domain (that compensates for 
the increased frustration in the social domain).

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Toxic people will not be changed by the alchemy of your kindness. Yes, be 
kind, but move on swiftly and let life be their educator.”
— Brendon Burchard

Re: How can we decrease the cognitive overhead for contributors?

[Development of GNU Guix and the GNU System distribution.]

Attila Lendvai  writes:

> here's an approximate list of what's consuming/training my 
> frustration-tolerance with Guix:
>
>  - debbugs and related tooling. i could live with an email based
>workflow, but whatever is documented, or at least whatever i have
>put together locally, is very inefficient. the chore vs. coding
>ratio is low.
>
>  - large backlog. contributions somtimes even fall through the cracks.
>
>  - strict adherence to changelog style commit messages without a
>clearly worded and documented argument about why it's worth the
>effort in 2023. whenever 'C' fails to add an entry to the commit
>message in Emacs, i groan out loud.

This is almost exactly my list. I strongly suspect that the issue with
the backlog and lost issues has a lot to due with debbugs just not
cutting the mustard.

I've got something like 6 patches waiting, all have been sitting around
for many months. They'll get some committer attention and then it drops
off and nothing happens. To me, that sounds like people lose track of
it, because debbugs doesn't allow people to stay easily on top of
patches they're interested in. Possibly we need some kind of concept of
patch stewards that can see something through.

I have more things I want to do with Guix, but it's tough, because I
have to maintain each of my patches separately in different branches, so
that I can rebase them as necessary and resubmit them cleanly if
necessary, or simply just to work on them when issues come up. But my
master branch pulls in each of them, so any time I need to pull, I've
got a list of things (switch to every branch, rebase, fix if necessary,
switch back to master, reset to origin/master, then merge all the
branches I'm maintaing). Adding more branches on top of the ones I
already have is just too much.

Regarding the GNU changelog commits, I really dislike them. They're
redundant busy-work as far as I'm concerned. And while I'd like to say
they're no longer necessary, because we have better tooling, I'm old
enough to be familiar with hand editing RCS and CVS files to fix
them. And even back then, in the dark days, only GNU used that
format. Just like today. So I'd argue they've always been pointless
busy-work.

I really like Guix, I like what it promises, I love the community around
it, and that's what keeps me here. But it's a deeply frustrating
experience to try to contribute to. I've been a contributor in various
forms to a great many free and open source software projects over the
years, and Guix is easily one of the worst in that regard.

-bjc

Re: How can we decrease the cognitive overhead for contributors?

[Ricardo Wurmus]

"Danny Milosavljevic"  writes:

> I agree that automating the technical steps of contributing to Guix
> would be nice.

We could provide a VM.  Guix can create systems well enough to make this
feasible, I think.

> This definitely should be automated. Why not generate a UUID locally and send
> a mail to @debbugs.gnu.org ? That may require changes to debbugs,
> though.

We cannot change the shared debbugs instance, which is why I think we
should take a closer look at self-hosting sourcehut.

-- 
Ricardo

Re: How can we decrease the cognitive overhead for contributors?

[Attila Lendvai]

> I've got something like 6 patches waiting, all have been sitting around
> for many months. They'll get some committer attention and then it drops
> off and nothing happens. To me, that sounds like people lose track of
> it, because debbugs doesn't allow people to stay easily on top of
> patches they're interested in. Possibly we need some kind of concept of
> patch stewards that can see something through.


yep, same impression here.


> I have more things I want to do with Guix, but it's tough, because I
> have to maintain each of my patches separately in different branches, so
> that I can rebase them as necessary and resubmit them cleanly if
> necessary, or simply just to work on them when issues come up. But my
> master branch pulls in each of them, so any time I need to pull, I've
> got a list of things (switch to every branch, rebase, fix if necessary,
> switch back to master, reset to origin/master, then merge all the
> branches I'm maintaing). Adding more branches on top of the ones I
> already have is just too much.


here's a script that i use to prepare an 'attila' branch that i can `guix pull` 
from:

$ cat ../rebase-my-guix-branches.sh
#!/usr/bin/env bash

BRANCHES="kludges ui-warnings trezor4"
# kludges-sent shepherd-from-git
# ddclient idris

set -e

initial_branch=$(git branch --show-current)

git rebase attila-baseline attila-initial-commit

git checkout attila
git reset --hard attila-baseline
git pull . attila-initial-commit

for branch in ${BRANCHES}; do
echo "*** Processing branch ${branch}"
#git rebase attila-baseline $branch
git cherry-pick attila-baseline..$branch
done

#git checkout $initial_branch

git -c pager.log=false log --pretty=oneline 
attila-initial-commit~1..attila-initial-commit



explanation:

i `git tag -f attila-baseline` on some commit, typically i pull master and on 
its head. then i have a branch called attila-initial-commit that holds a single 
commit that adds my key as authorized.

this script cherry-picks all the listed branches, and at the end it prints the 
commit hash of the initial commit that i can then copy-paste into my 
channels.scm file.

whenever cherry-picking fails, i abort it, manually rebase the branch in 
question, and then restart the script.

HTH,

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Freedom is strangely ephemeral. It is something like breathing; one only 
becomes acutely aware of its importance when one is choking.”
— William E. Simon

Re: How can we decrease the cognitive overhead for contributors?

[Efraim Flashner]

On Mon, Sep 04, 2023 at 10:56:39AM +0200, Ricardo Wurmus wrote:
> 
> Vagrant Cascadian  writes:
> 
> > The only thing clunky about this particular aspect of the workflow
> > described is the fact that the guix community (maintainers?) have
> > decided on a one patch per mail policy with a cover letter, rather than
> > submitting the patches as attachments in the initial mail.
> 
> You are right.  When I started contributing I actually did attach all
> patches in one email.  I wonder why we stopped doing that.

I believe some found it easier to pipe multiple emails to git am than to
pipe attachments. From mutt there's no difference for me.

> I’ll say that many of my gripes with (the GNU instance of) Debbugs are
> due to the fact that we can’t customize it to better suit our needs — it
> is a shared resource with a complicated maintenance story.  So all
> changes went into Mumi as crude workarounds.  I think this is a dead end
> and we’d be better off leaving the shared GNU instance of Debbugs
> behind.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Current Issues with Patch Review Workflow Using git.guix-patches.cbaines.net

[jgart]

Hi Guixers,

Andreas' detailed a nice workflow for reviewing patches in a previous thread*:

```
git clone https://git.guix-patches.cbaines.net/guix-patches/
git checkout issue-x
git format-patch ...
then in the development checkout of Guix:
git am ...; make; ./pre-inst-env guix build
```

I noticed that there is one issue with this approach after trying it.

Old tickets are not kept around.

For example, A branch for ticket 51810* does not exist anymore.

But that ticket is still open 🙃

Hi Christopher,

Would it be possible to keep around branches for any open tickets?

Should stale tickets like 51810 be automatically closed so that 
git.guix-patches.cbaines.net* gets comprehensive coverage of ticket/branch 
pairings?

best,

jgart

* https://lists.gnu.org/archive/html/guix-devel/2023-08/msg00158.html
* https://issues.guix.gnu.org/51810
* https://git.guix-patches.cbaines.net/guix-patches/

Re: Current Issues with Patch Review Workflow Using git.guix-patches.cbaines.net

[Andreas Enge]

Hello jgart,

Am Mon, Sep 04, 2023 at 05:48:05PM + schrieb jgart:
> Old tickets are not kept around.
> For example, A branch for ticket 51810* does not exist anymore.

this is probably due to the fact that the git repo did not yet exist
at the time. The oldest issue I see is 60286 from December 2022, which
looks compatible with this hypothesis.

So this patch fell completely through the cracks! We should indeed
spend some time going through old tickets (this, for instance, at first
glance looks like it could be applied, others may simply be dropped).

Andreas

Re: Current Issues with Patch Review Workflow Using git.guix-patches.cbaines.net

[jgart]

>> Old tickets are not kept around.

Hi,

Oh ok, old tickets were never included instead of old tickets being deleted.

I'm not familiar with this code yet.

Thanks for the clarification.

Re: How can we decrease the cognitive overhead for contributors?

[Andreas Enge]

Am Mon, Sep 04, 2023 at 08:44:18AM -0400 schrieb brian via Development of GNU 
Guix and the GNU System distribution.:
> >  - strict adherence to changelog style commit messages without a
> >clearly worded and documented argument about why it's worth the
> >effort in 2023. whenever 'C' fails to add an entry to the commit
> >message in Emacs, i groan out loud.
> Regarding the GNU changelog commits, I really dislike them. They're
> redundant busy-work as far as I'm concerned. And while I'd like to say
> they're no longer necessary, because we have better tooling

As said before, I use them all the time through
   git log | grep "whatever I am looking for"
or the interactive
   git log
then "/" for searching inside the less command; I find it useful to a point
that I have moved to this style for all my coding projects.

So as far as I am concerned, they are tremendously useful. Well, that may
be due to a lack of git knowledge, of course! But while in other projects
I often find I need to look at the content of commits, in Guix it is often
enough to just look at the changelog.

Andreas

Re: How can we decrease the cognitive overhead for contributors?

[Andreas Enge]

Am Mon, Sep 04, 2023 at 10:23:45AM + schrieb Attila Lendvai:
>  - large backlog. contributions somtimes even fall through the cracks.

My impression/hope is that the recent introduction of teams leads to
improvements on this front. I am on the science and texlive teams and
have been getting emails from the patch submission workflow; so these
end up in my inbox and I feel responsible for them. As a consequence,
I have been reviewing more commits recently.

For this to work, we would need a 100% coverage of modules by teams
(a necessary, not a sufficient condition...). A consequence of my
focussing on email is that I essentially ignore everything that does
not come in by email (well, I also look at the green badges in QA
from time to time). So, my impression/hope is that also QA leads to
improvements.

This does not solve the problem of finite time and competence, however.

Andreas

Re: Current Issues with Patch Review Workflow Using git.guix-patches.cbaines.net

[Christopher Baines]

"jgart"  writes:

> Hi Guixers,
>
> Andreas' detailed a nice workflow for reviewing patches in a previous thread*:
>
> ```
> git clone https://git.guix-patches.cbaines.net/guix-patches/
> git checkout issue-x
> git format-patch ...
> then in the development checkout of Guix:
> git am ...; make; ./pre-inst-env guix build
> ```
>
> I noticed that there is one issue with this approach after trying it.
>
> Old tickets are not kept around.
>
> For example, A branch for ticket 51810* does not exist anymore.
>
> But that ticket is still open 🙃
>
> Hi Christopher,
>
> Would it be possible to keep around branches for any open tickets?

Yes and no.

Currently the QA frontpage creates branches for the latest 350 [1] patch
series, and it'll remove them if they slip outside of the latest 350.

1: 
https://git.cbaines.net/guix/qa-frontpage/tree/scripts/guix-qa-frontpage.in#n238

Increasing that number is possible, but not really feasible at the
moment since the branch existing feeds in to data.qa.guix.gnu.org
potentially keeping data around for that revision, which has a cost in
disk space, and beid (the machine running data.qa.guix.gnu.org) is
really low on disk space at the moment (23G available out of 338G).

There's also an ongoing cost in that the QA frontpage tries to reapply
patches when big changes happen in the master branch, which involves
more work for the data serivce the more branches you're trying to
manage.

Having more hardware for data.qa.guix.gnu.org, and speeding it up would
help. Another approach would be to have the QA frontpage push these
older patch branches with a slightly different name (that the data
service would ignore), or push them to a different remote. That would
mean that the branch would still be somewhere, but the data service
would ignore it.

> Should stale tickets like 51810 be automatically closed so that
> git.guix-patches.cbaines.net* gets comprehensive coverage of
> ticket/branch pairings?

I don't think automatically closing older issues is helpful, they still
need looking at.


signature.asc
Description: PGP signature

RE: How can we decrease the cognitive overhead for contributors?

[phil]

>I really like Guix, I like what it promises, I love the community around
it, and that's what keeps me here. But it's a >deeply frustrating experience
to try to contribute to. I've been a contributor in various forms to a great
many free >and open source software projects over the years, and Guix is
easily one of the worst in that regard.

This aligns with somewhat with my (limited) experience.  I'm a massive fan
of Guix, but I did find the process a bit opaque; even after seeking
clarification from the mailists, and some of my patches eventually fell
through the cracks, or in other cases, someone would kindly submit on my
behalf.  That's really nice of them to do, but it's obviously not the way
things should work.

I've contributed to other Guix channels (some run by people closely
affiliated with Guix proper) and other open source projects and found the
overhead is usually no more than few minutes to read/follow to the how-to
guide.  I don't have a favourite forge nor a specific process I want to
promote - but it should be easy and require little effort to understand and
setup.  Really the typical use-case should be close to push-button - with
the focus being on reviewing the contribution rather than the mechanics of
how this is done.

I (and other colleagues) have a bunch of core enhancements, and quite a few
packages sat in my (now previous) company's Guix channel that would be great
to get into Guix proper (if the wider community deem them appropriate/useful
of course!), but the overhead means we kept avoiding getting this done and
the company runs off a lagged fork of Guix they manually update and rebase
themselves, rather than pushing their work upstream into Guix.

I 100% accept failing to get patches into Guix proper is also lethargy on my
behalf, and perhaps I'm guilty of carping rather than proactively helping,
but in choosing what to contribute to, and when spare-time is sadly limited,
the amount of overhead and chasing required both become inevitable
considerations on where to focus time.

Mumi CLI client (was: How can we decrease the cognitive overhead for contributors?)

[Arun Isaac]

Hi all,

I'm glad we're having this difficult but necessary conversation.

I have been following the conversation with much interest. There seems
to be a developing consensus that we should switch to sourcehut. I am
all in favour of any decision the community comes to on this.

But, meanwhile, I wish to remind everyone that we already have a mumi
CLI client that takes away some of the pain of dealing with Debbugs. It
operates fully on the command-line and does not require Emacs at
all. This CLI client has so far been undocumented. So, I thought it
helpful to document it and put it into the manual. I have sent a patch
to https://issues.guix.gnu.org/65746

Regards,
Arun

Re: Current Issues with Patch Review Workflow Using git.guix-patches.cbaines.net

[jgart]

> I don't think automatically closing older issues is helpful, they still
> need looking at.

Or instead of closing them, put the patch into a state that is not open. Like 
an archived state or some other state that does not require action until 
someone takes ownership of the issue and resolves it.

I think this can prevent being overwhelmed by the number of open issues that 
are not high priority, lack reviewers, or are so grossly outdated and that they 
require completely starting from scratch in order to work on it.

Re: How can we decrease the cognitive overhead for contributors?

[Maxim Cournoyer]

Hi,

Katherine Cox-Buday  writes:

[...]

> Here's my understanding of the process to contribute a patch:
>
>   1. Check out main, and run `./bootstrap`, then `./configure
> --localstatedir=/var --sysconfdir=/etc`
>   2. Run `make`
>   3. You need to determine whether the change can be targeted against
> main or
>  needs to target a feature branch, so you go read about that.
>
> [I'm usually starting here]
>
>   4. Run `./pre-inst-env guix refresh --list-dependent `
>   5. Create a git worktree for your patch
>   6. Run `./bootstrap`, then `./configure --localstatedir=/var
> --sysconfdir=/etc`
>   7. Run `make`
>   8. Make your changes
>   9. Build to ensure your changes are workable.
>   10. Try and determine how your changes should be factored into individual
>   commits (sometimes it's not always so clear when changing two
> things might
>   need to be done atomically).
>   11. Try and get each commit message close to correct and commit.
>   12. Run `guix lint`
>   13. Run `guix style` (this is still in the manual although I have since
>   learned this is not actually advisable).

The intent is for it to be advisable -- when it's not, a bug should
be/have been reported against it to track its resolution.

[...]

>   19. Run `guix pull --url=/path/to/your/checkout
> --profile=/tmp/guix.master` to
>   ensure you didn't break Guix in a different way.

'make as-derivation' is probably more efficient to test for that

>   20. Run `git format-patch -1 --cover-letter [--reroll-count]`
>   21. Run `./pre-inst-env ./etc/teams.scm cc-members ` to get
> the CC flags for Git
>   22. Remember that if you're sending multiple patches, an email first
> has to be
>   sent to `guix-patc...@gnu.org` to get an ID, and then...
>   23. Run `git send-email --to guix-patches  `

You don't need to manually do 21 (and add the cc flags in 23), as
advances to git and our teams.scm script automates that for you (the
patches are checked for which files they touched; and the team, if any,
that has such files in their scope is CC'd via a X-Debbugs-CC header).

--
Thanks,
Maxim

Re: native-search-path and guix profile

[Maxim Cournoyer]

Hi Hartmut,

Hartmut Goebel  writes:

> Good afternoon.
>
> I'm curious about how exactly native-search-path work.
>
> I packaged vagrant, which needs to find plugins, therefore I defined a
> native-search-path, see
> .
>
> This works fine when using "guix shell vagrant vagrant-my-plugin": The
> env variable is set and vagrant finds the plugin. Now when installing
> vagrant and the plugin into my profile, this env variable is not set
> and vagrant fails to find the plugins installed. Also neither
> GUIX_PROFILE nor GUIX_ENFIRONMENT are set, thus using these as a base
> does not work either.

If it works in a guix shell profile, it should work the same in your
user profile, so I'm not sure where's the issue.

-- 
Thanks,
Maxim

Re: questionable advice about Geiser load path setting

[Maxim Cournoyer]

Hello,

wolf  writes:

[...]

> Geiser seems to add the project root (I assume based on the git) into the load
> path automatically.  geiser-repl-current-project-function seems to be set by
> default, and rest is described in the docs: (geiser)Customization and tips, 
> Init
> files and load paths.
>
> Maybe it once was necessary to set this, I am not sure it still is the case.
>
> I also use (setq geiser-repl-per-project-p t) and everything seems to just 
> work
> out of the box.

I haven't followed up with the latest Geiser features, but if what you
wrote is true, then it would be nice to streamline our .dir-locals.el
and simply set geiser-repl-per-project-p to t (as a directory-local
variable).

Would you like to see if that continues working the same, across
e.g. Git worktrees of Guix checkouts?

-- 
Thanks,
Maxim

Re: CI job for lisp-team branch

[Maxim Cournoyer]

Hi Guillaume,

Guillaume Le Vaillant  writes:

> Hi.
> I created a lisp-team branch to work one some updates for clisp and
> sbcl. Could someone with admin access to the CI things add a job for it?
> Thanks.

I've also created a TLS client certificate and emailed it to you
(encrypted) so that you can manage your branch yourself via the Cuirass
web interface, restart failing builds (which are sometimes spurious
failures due to not yet resolved CI/infrastructure problems such as
#54447).

Cheers!

-- 
Thanks,
Maxim

Python Team: Keeping Branch Up To Date Question

[jgart]

Hi Lars,

What is the git approach for keeping the Python branch up to date? 🦆

Should I be rebasing off of master or something else?

I'm trying to review this patch:

https://issues.guix.gnu.org/64973

Any advice much appreciated.

all best,

jgart

Re: How can we decrease the cognitive overhead for contributors?

[Maxim Cournoyer]

Hi Ricardo,

Ricardo Wurmus  writes:

> Vagrant Cascadian  writes:
>
>> The only thing clunky about this particular aspect of the workflow
>> described is the fact that the guix community (maintainers?) have
>> decided on a one patch per mail policy with a cover letter, rather than
>> submitting the patches as attachments in the initial mail.
>
> You are right.  When I started contributing I actually did attach all
> patches in one email.  I wonder why we stopped doing that.

It's still allowed as far as I know.  But due to missing out on
notifying team members automatically (handled by 'git send-email') and
sometimes causing issues for reviewers to apply patches, it's
understandable that 'git send-email' is the most recommended option.

> I’ll say that many of my gripes with (the GNU instance of) Debbugs are
> due to the fact that we can’t customize it to better suit our needs — it
> is a shared resource with a complicated maintenance story.  So all
> changes went into Mumi as crude workarounds.  I think this is a dead end
> and we’d be better off leaving the shared GNU instance of Debbugs
> behind.

I'd be sad to loose at least two good things from Debbugs:

1. It's hosted by the GNU/FSF for us.  It always work, and the rare
times it doesn't, the folks in #savannah are hard at work resolving the
problems. While hosting sourcehut is probably not too difficult, keeping
it up to date (Go...) and running would be yet another weigh on our
meager sysadmin team.

2. Integration with Emacs.  emacs-debbugs is useful.  I think it's the
only successful thing we have at keeping track of old tickets and
resuming discussion or acting on these.

I like how clean Mumi looks, compared to most forge issue trackers.  I'm
not convinced by its search results (perhaps I'd need to get to know
what Xapian is).

-- 
Thanks,
Maxim

Pinned/fixed versions should be a requirement.

[Distopico]

In my experience using Guix and attempting to make contributions, I've
noticed that the vast majority of times when a library breaks, it's
because one of its dependencies changed version. For instance,
referencing something like `rust-my-lib-1`, where "1" refers to the
semver "1.x" of the package, e.g., "1.0.32", and `rust-foo` depends on
`rust-my-lib == 1.0.32`. However, in some other package got updated to
"1.0.34" so `rust-foo` will break. I've seen this happen a lot with
Haskell and Rust libraries.

Many libraries in different languages don't follow semver, which can
lead to cases like `rust-serde-json`, which, between versions "1.0.97"
and "1.0.98," changed its dependency from `indexmap` "1.x" to "2.x,"
causing several packages like rust-analyzer to break. I've also observed
this in Haskell with packages like "text."

This is problematic because:

- Over time, it becomes more vulnerable to libraries/packages
  breaking.

- It makes reproducible software more challenging, as "1.x" can
  encompass many versions.

- Debugging becomes difficult since that package could be a deep
  dependency in the system package dependency chain, such as
  Rust/Haskell/NPM, etc.

- It makes it more likely that if a dependency changes, many
  packages will need to be updated/rebuilt due to that change.

For these reasons, I believe that pinned versions should be a
requirement in libraries, always specifying the exact dependency, for
example, `rust-serde-json-1.0.98`.

This brings the following benefits:

- Fewer packages will be prone to rebuilding when changing the
  definition of a library.

- Reduced likelihood of libraries/packages breaking.

- Easier maintenance of packages and libraries without fear of
  breaking others or having to update many.

There could be some potential disadvantages:

- The list of library versions may grow larger, making it harder to
  detect orphaned or unused versions.

Additionally, I believe that a command to list the dependency tree of a
package would be ideal for easier debugging.

Regards!


signature.asc
Description: PGP signature

Re: How can we decrease the cognitive overhead for contributors?

[Maxim Cournoyer]

Hi,

Ricardo Wurmus  writes:

> "Danny Milosavljevic"  writes:
>
>> I agree that automating the technical steps of contributing to Guix
>> would be nice.
>
> We could provide a VM.  Guix can create systems well enough to make this
> feasible, I think.

I'm not convinced.  I typically uses VM for testing quick hacks on
foreign systems, not as my main development environment.  I doubt the
experience would be helped much.  We have 'guix shell' :-).

-- 
Thanks,
Maxim

Re: package definition question: referring to source files of another package?

[Andy Tai]

Thanks. this is the pattern that seems to work, posted here for reference:
(define-public tensorflow-lite
  (package
(name "tensorflow-lite")
 ...
(arguments
 `(#:configure-flags

   (list ...
(string-append "-Dgemmlowp_SOURCE_DIR=" (assoc-ref
%build-inputs "gemmlowp-src"))
...

(inputs
 `(
   ("gemmlowp-src"
  ,(package-source gemmlowp))
...

where A is tensorflow-lite and B is gemmlowp

On Sat, Sep 2, 2023 at 9:18 PM Liliana Marie Prikler
 wrote:
> Am Samstag, dem 02.09.2023 um 20:35 -0700 schrieb Andy Tai:
> > In some scenarios package A may refer to source files in package B.
> > The question is,
> > 1. How to reference source directory of package B from within
> > definition of package A?
> You can use (package-source B) both within source and inputs.  The only
> caveat here is that A and B should best be located in the same file;
> things break badly if they are split and introduce cyclic references.
> Note that the and part is more likely than you think, since the thunked
> nature of inputs normally makes them harmless.
>
> Cheers