guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Golang mudules to follow common grouping


From: Maxim Cournoyer
Subject: Re: Golang mudules to follow common grouping
Date: Sat, 20 Jan 2024 13:33:31 -0500
User-agent: Gnus/5.13 (Gnus v5.13)

Hi Christina,

Christina O'Donnell <cdo@mutix.org> writes:

> Hi Oleg,
>
> On 13/01/2024 21:05, Sharlatan Hellseher wrote:
>> Hi Guix,
>>
>> I'm about to prepare split and aggregation of all golag packages
>>  related to cryptography. The process would be the same as for
>>  golang-check and golang-web.
>>
>>
>> In progress:
>> golang-cryptography
>>
>> Planned:
>> golang-compression
>> golang-build
>
> I just wanted to offer my labor to this task. I'm very new to guix
> development
> (I've only packaged one package so far), but I've got a fair amount of
> free time
> and I've been looking for ways to contribute to Guix. (Plus I've
> already got my
> head in golang.scm trying to package gitleaks and all its dependencies.)

Thanks for offering to help!  The most important part in doing so is to
synchronize with the other members of the Go team to avoid duplicating
the work, I think.

> I know that there's a lot to do already, but I was also wondering whether
> they're going in any particular order once they're moved. There's a
> comment at
> the end of golang.scm that says,
>
>> ;;; Avoid adding new packages to the end of this file. To reduce the
>       chances
>> ;;; of a merge conflict, place them above by existing packages with
>       similar
>> ;;; functionality or similar names.
>
> Would it be more organized if they was just one order: either in
> alphabetical
> order or grouped by function? My suggestion would be to use the file
> split to
> group by function and then sort each file alphabetically. Do you know
> how it is
> arranged for other languages?

That'd be neat, but in practice is hard to maintain as the module
becomes quite large and people easily (and understandably) miss the
intended grouping when adding new packages.

> Another question I have: Is there any tooling that can help big package
> migrations like this go faster? Eg. a script to split one big diff into
> individual package moves with appropriate change-log entries.

Not that I'm aware of.

-- 
Thanks,
Maxim



reply via email to

[Prev in Thread] Current Thread [Next in Thread]