Re: Golang mudules to follow common grouping

[Maxim Cournoyer]

Hi Sharlatan,

Sharlatan Hellseher  writes:

> Hi Guix!
>
> I've pushed split IV
> https://issues.guix.gnu.org/69042
>
> Now there are all base golang-* modules which I'm about to populate on demand
> during patch review.
>
> - golang-build
> - golang-check
> - golang-compression
> - golang-crypto
> - golang-web
> - golang-xyz
>
> These two may be added as well if I see enough packages related to that topic.
> - golang-graphics
> - golang-maths / golang-science

Great work!  Thank you for seeing it through!

-- 
Thanks,
Maxim

Re: Golang mudules to follow common grouping

[Sharlatan Hellseher]

Hi Guix!

I've pushed split IV
https://issues.guix.gnu.org/69042

Now there are all base golang-* modules which I'm about to populate on demand
during patch review.

- golang-build
- golang-check
- golang-compression
- golang-crypto
- golang-web
- golang-xyz

These two may be added as well if I see enough packages related to that topic.
- golang-graphics
- golang-maths / golang-science

Thanks,
Oleg


-- 
VCS: https://github.incerto.xyz/; https://git.sr.ht/~hellseher/
GPG: 9847 81DE 689C 21C2 6418 0867 76D7 27BF F62C D2B5

… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.

Re: Golang mudules to follow common grouping

[Sharlatan Hellseher]

Hi,

I stick to this flow
- pick a package from golang.scm e.g. go-package-a
- identify destination (any of golang-*.scm)
- place go-package-a to e.g. golang-web.scm in alphabetic order
- remove go-package-a from golang.scm
- by using magit find all authors contributing to go-package-a
- place found copyright headers to golang-web.scm if they are unique
- grep -l -r go-package-a gnu/packages/
- identify if the module(s) missing use-module (gnu packages golang-web),
add if so
- guix build go-package-a
- build all dependent to go-package-a
- make a commit ...
...
repeat as many times as needed.


Batch of 40-50 is a golden median amount to review.

Thanks,
Oleg

Re: Golang mudules to follow common grouping

[Christina O'Donnell]

Hi,

Okay that's a better plan :)


Let's use  Occam's razor for now. We have few common groups,
the task is to drop use-module (gnu packages golang) for each
of them by sorting packages into recently introduced modules.
Right, put the dependencies in of golang-web in golang-web (etc.) as 
much as sensibly possible.


How about when a library is used by many packages in more than one 
different modules?


Kind regards
- Christina

On 05/02/2024 14:00, Sharlatan Hellseher wrote:

Hello,

Thank you for your research on that, I was not expected to go
far like you did :-)

My short plan was to follow existing naming model which is in
use for python-*.scm, lisp-*.scm, perl-*scm, java-*.scm.
I see that golang would need some extra modules in the future
and comparing with python-*.scm the package base is not big
yet.

Let's use  Occam's razor for now. We have few common groups,
the task is to drop use-module (gnu packages golang) for each
of them by sorting packages into recently introduced modules.

- golang-web.scm
- golang-check.scm
- golang-xyz.scm
- golang-crypto.scm

Thanks,
Oleg

Re: Golang mudules to follow common grouping

[Sharlatan Hellseher]

Hello,

Thank you for your research on that, I was not expected to go
far like you did :-)

My short plan was to follow existing naming model which is in
use for python-*.scm, lisp-*.scm, perl-*scm, java-*.scm.
I see that golang would need some extra modules in the future
and comparing with python-*.scm the package base is not big
yet.

Let's use  Occam's razor for now. We have few common groups,
the task is to drop use-module (gnu packages golang) for each
of them by sorting packages into recently introduced modules.

- golang-web.scm
- golang-check.scm
- golang-xyz.scm
- golang-crypto.scm

Thanks,
Oleg

Re: Golang mudules to follow common grouping

[Christina O'Donnell]

Hi again Oleg,

> > I think you may help! The identification of the group is still human
> > decision making process and I'm not sure it may be automated in any 
point.

>
> I can certainly help with this then. I'll have some free time on 
Friday and

> I can coordinate with you then.
Ah, I lost track of time..

Okay, so I wrote a grotesque shell script that extracted the name, synopsis,
and description from each package. Then I manually chunked the output into a
transformer, asking it to:

  "Given a list of packages and descriptions, please[1] suggest ways of
   categorizing them (by function or theme) in a way that keeps each 
category

   about equal size."

...followed by 5 paragraphs of minutia to make sure it does the right thing.

Then I give it 200 lines of packages ~36 packages. It gives me its output
which is inevitably missing one or more of the constraints I gave it, so I
say "Did you follow my instructions?" [2] After this, it either gives me an
output with one less thing wrong with it and an apology, or goes off in a
huff and wastes all my GPU credit.


Things that are standing out so far are:

 - golang-web.scm could become a broader golang-networking.scm
 - golang-crypto.scm could become a broader golang-security.scm
 - There could be a need for a golang-text.scm that focusses on text 
parsing and

   processing.
 - A golang-utils could exist, however this could easily become the 'other'
   file.

Anyway, point is: I've got a very poor classification of packages in
golang.scm. I want to refine that using a langchain script. However, before
I move anymore forward with this, I wanted to ask: Is it okay to use AI
tools that are non-free in the aid of the GNU project?

> > We may extend handy script accelerating committing process, see
> > "etc/committer.scm"
>
> Okay, cool, I'll have a look at it on Friday.

Great, I haven't had a chance to look at this yet, but I will early next 
week.


Here's a link to my repo: https://github.com/cdo256/guix-package-refactor

Let me know what you think.

Kind regards,
 - Christina

[1] I am always polite to AI.
[2] Welcome to modern programming, people. Feels more like primary school
children.

Re: Golang mudules to follow common grouping

[Christina O'Donnell]

Hi Oleg,


I've pushed the split III to master.


Fantastic work!


I think you may help! The identification of the group is still human
decision making process and I'm not sure it may be automated in any point.


I can certainly help with this then. I'll have some free time on Friday and
I can coordinate with you then.


Each of the module header contains a  short annotation which packages it
 expects to have, feel free to improve it to make it even more clear
for  others.

-  golang-check
-  golang-web
-  golang-crypto

TBA:
-  golang-compression :: Anything related to that subject, see
 python-compression, java-compression, perl-compression.

-  golang-build or golang-extension :: Any low level golang add-ons not
 included in core distribution see  or
any 0  dependencies high reference modules.

-  golang-xyz :: As any other *-xyz module would absorb anything else
  left  behind.


This all sounds sensible to me.


1.  Put a magic comment above each package that you would like to move.
2.  Run a simple script that makes a note of all of these into a
 to-move-list.
3.  Then stash the change with the comments you made (in case you need
to  change things)
4.  Run another script that takes the package list and performs the
 move in one's repository.
5.  Sort out the use-package declarations manually and run tests.
6.  When satisfied, stash the change and keep just the use-package
 changes.
7.  Run a final script that loops through all the packages and commits
 each one in turn.
8.  Rebase to suit.


We may  extend handy script accelerating committing process, see
 "etc/committer.scm"


Okay, cool, I'll have a look at it on Friday.


-  I'm not a scheme programmer, but I did use Haskell at university so
 I'm familiar with thinking in a functional style.

Me too  =), but you still can help by just providing some review to
 existing code base and available packages in golagn.scm and trying to
 identify close group for each of them.


 I'm also imagining some the possibility of having a script that can
 remove redundant #:use-module's in the future, though I don't know if
we  care about a few unneeded modules being included.

The  clean up task may be organasied after sort process is completed, having
not  required #:use-module does not hurt too much but for keeping modules
tidy  and fast to load it definitely beneficial.


This makes sense. Not a priority at present but a nice-to

Looking forward to hacking golang.scm to pieces!

Kind regards,
 - Christina

Re: Golang mudules to follow common grouping

[Sharlatan Hellseher]

Hi,

I've pushed the split III to master.
- https://issues.guix.gnu.org/68605
- https://debbugs.gnu.org/cgi/bugreport.cgi?bug=68605

And it's picked up by CI.
- https://ci.guix.gnu.org/eval/1082575

> Hmm, there seems to be a limit in the degree of parallelizability in
> this process unfortunately. But if there's anything you can think of
> that could help (manually) in this effort, then I'd be happy to help!

I think you may help! The identification of the group is still human
decision making process and I'm not sure it may be automated in any point.
So...
There are golang dedicated modules now and few more coming soon!

Each of the module header contains a short annotation which packages it
expects to have, feel free to improve it to make it even more clear
for others.

- golang-check
- golang-web
- golang-crypto

TBA:
- golang-compression :: Anything related to that subject, see
  python-compression, java-compression, perl-compression.

- golang-build or golang-extension :: Any low level golang add-ons not
included in core distribution see  or
any 0 dependencies high reference modules.

- golang-xyz :: As any other *-xyz module would absorb anything else
  left behind.

Maybe:
- golang-graphics
- golang-maths / golang-science
- ...

> 1. Put a magic comment above each package that you would like to move.
> 2. Run a simple script that makes a note of all of these into a
> to-move-list.
> 3. Then stash the change with the comments you made (in case you need
> to change things)
> 4. Run another script that takes the package list and performs the
> move in one's repository.
> 5. Sort out the use-package declarations manually and run tests.
> 6. When satisfied, stash the change and keep just the use-package
> changes.
> 7. Run a final script that loops through all the packages and commits
> each one in turn.
> 8. Rebase to suit.

We may extend handy script accelerating committing process, see
"etc/committer.scm"

> - I'm not a scheme programmer, but I did use Haskell at university so
>  I'm familiar with thinking in a functional style.
Me too =), but you still can help by just providing some review to
existing code base and available packages in golagn.scm and trying to
identify close group for each of them.

> I'm also imagining some the possibility of having a script that can
> remove redundant #:use-module's in the future, though I don't know if
> we care about a few unneeded modules being included.
The clean up task may be organasied after sort process is completed, having
not required #:use-module does not hurt too much but for keeping modules
tidy and fast to load it definitely beneficial.

Regards,
Oleg


signature.asc
Description: PGP signature

Re: Golang mudules to follow common grouping

[Christina O'Donnell]

Hi Oleg,

> I've added comments in commentary section in the top of the file 
asking to

> keep packages alphabetically sorted seen in julia-xyz.scm as well.
> python-*.scm ordered semi random grouped closer to package purpose which
> require more thinking where to put a new one :-)

Ah, I suppose it isn't that important given you can grep for the right
package.

> Good point her, I did manual split, with Emacs keyboard macros, magit 
history
> scan for copyright lines and manual check where package was used to 
include

> new module name.
>
> The split into golang-crypto is in review now and there would be 2 
more common

> grouping: golang-compression and golang-build (or golang-extension). Rest
> packages which are hard to determine a group wound go to generic 
golang-xyz

> sorted alphabetically.

Hmm, there seems to be a limit in the degree of parallelizability in this
process unfortunately. But if there's anything you can think of that 
could help

(manually) in this effort, then I'd be happy to help!

> Let me know your tooling which you familiar with I might think
> about some sort of automation.

I've had a grep around the web and I can't see any tools or libraries 
that have
been created already to perform functions like this. I know everyone has 
their
own scripts (I've got one written in shell but it won't be of much use 
here. I

would suggest writing it in Scheme so it could be easier to add more complex
features and it's familiar to Guix developers.

 1. Put a magic comment above each package that you would like to move.
 2. Run a simple script that makes a note of all of these into a 
to-move-list.
 3. Then stash the change with the comments you made (in case you need 
to change

    things)
 4. Run another script that takes the package list and performs the move in
    one's repository.
 5. Sort out the use-package declarations manually and run tests.
 6. When satisfied, stash the change and keep just the use-package changes.
 7. Run a final script that loops through all the packages and commits 
each one

    in turn.
 8. Rebase to suit.

That's 3 scripts:
 - xyz-source-transform-read-packages scm-filename package-list (for 
step 2)
 - xyz-source-transform-move-packages package-list from-filename 
to-filename

   (for step 4)
 - xyz-source-transform-stage-package-commit package-list from-filename
   to-filename (for step 7)

(Where 'xyz' is either 'guix' or something else depending on where the 
code ends

up part of Guix or not. That's not important for now.)

Some caveats:
 - I'm not a scheme programmer, but I did use Haskell at university so I'm
   familiar with thinking in a functional style.
 - For this to work, you'd have to update most package files that 
reference (gnu

   package golang) to also reference the new package, so there will be some
   use-module redundancy (which could be resolved in a final clean-up 
commit).


I'm also imagining some the possibility of having a script that can remove
redundant #:use-module's in the future, though I don't know if we care 
about a

few unneeded modules being included.

I'd love to hear what you think before I fire up another emacs instance. 
Does it

sound like a realistic workflow?

All comments welcome!

Kind regards,
 - Christina

Re: Golang mudules to follow common grouping

[Maxim Cournoyer]

Hi Christina,

Christina O'Donnell  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

Re: Golang mudules to follow common grouping

[Sharlatan Hellseher]

Hi Christina,

> 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?

I've added comments in commentary section in the top of the file
asking to keep packages alphabetically sorted seen in
julia-xyz.scm as well. python-*.scm ordered semi random grouped
closer to package purpose which require more thinking where to put a new
one : -)

> 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.

Good point her, I did manual split, with Emacs keyboard macros,
magit history scan for copyright lines and manual check where
package was used to include new module name.

The split into golang-crypto is in review now and there would be 2 more
common grouping: golang-compression and golang-build (or
golang-extension). Rest packages which are hard to determine a
group wound go to generic golang-xyz sorted alphabetically.

Let me know your tooling which you familiar with I might think
about some sort of automation.

Thanks,
Oleg

Re: Golang mudules to follow common grouping

[Christina O'Donnell]

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.)

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?

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.

If you could share any scripts that you're using then that could help speed
up similar tasks in future.

Kind regards,
 - Christina

Re: Golang mudules to follow common grouping

[Sharlatan Hellseher]

Hi,

Part III of the split is sent for review,
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=68605

Thank,
Oleg
-- 
VCS: https://github.incerto.xyz/; https://git.sr.ht/~hellseher/
GPG: 9847 81DE 689C 21C2 6418 0867 76D7 27BF F62C D2B5

… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.

Re: Golang mudules to follow common grouping

[Maxim Cournoyer]

Hi Oleg,

Sharlatan Hellseher  writes:

> 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

This sounds like a good idea to me!  Thanks for volunteering to do this
laborious task.

-- 
Maxim

Re: Golang mudules to follow common grouping

[Sharlatan Hellseher]

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

Regards,
Oleg

On Mon, 30 Oct 2023, 01:17 Sharlatan Hellseher, 
wrote:

> Hi,
>
> Part II of the split https://issues.guix.gnu.org/66827
>
> Now we would have
> - golang.scm - which would be logically keep on minimal number of packages
> - golang-check.scm
> - golang-web.scm - in review
>
> Planed
> - golang-crypto.scm
> - golang-compression.scm
> - golang-build.scm - which would include low level 0 dependencies packages.
>
> I found a lot of golang packages in (gnu packages syncthing) which are not
> 100%
> related to syncthing itself, possibly the were left there long ago.
>
> Thanks,
> Oleg
>
> On Thu, 19 Oct 2023 at 10:40, Sharlatan Hellseher 
> wrote:
> >
> > Hi,
> >
> > I've accidentally included other patch to this series. I've re-sent it
> under the
> > new issue number https://issues.guix.gnu.org/66627.
> >
> > Thanks,
> > Oleg
> >
> >
> > On Mon, 16 Oct 2023 at 19:17, Sharlatan Hellseher 
> wrote:
> > >
> > > Hi,
> > >
> > > I'm about to create golang-check and golang-build modules, which both
> are core and would be in used by others. As Maxim mentioned, the most time
> consumption task would be migrating copyrights header properly.
> > >
> > > On Sun, 15 Oct 2023, 22:25 Wilko Meyer,  wrote:
> > >>
> > >>
> > >> Hi,
> > >>
> > >> Sharlatan Hellseher  writes:
> > >>
> > >> > I think it's time to split (gnu packages golang) into some logical
> groups, see
> > >> > Python, Lisp for example.
> > >> >
> > >> > Thoughts?
> > >>
> > >> IMHO this sounds like a good idea as it would improve the
> > >> maintainability of golang packages in the long run. We have 487
> package
> > >> definitions right now:
> > >>
> > >> (~/devel/guix-devel/gnu/packages) λ rg -c 'define-public' golang.scm
> > >> 487
> > >>
> > >> which already seems quite laborous to split into logical groups (while
> > >> getting the copyright information right as well and maintaining the
> > >> gitlog history etc.); so it probably classifies as a task that should
> be
> > >> tackled sooner than later as it'll cause more work over time the more
> > >> golang packages exist.
> > >>
> > >> --
> > >> Kind regards,
> > >>
> > >> Wilko Meyer
> > >> w...@wmeyer.eu
> >
> >
> >
> > --
> >
> > … наш разум - превосходная объяснительная машина которая способна
> > найти смысл почти в чем угодно, истолковать любой феномен, но
> > совершенно не в состоянии принять мысль о непредсказуемости.
>
>
>
> --
>
> … наш разум - превосходная объяснительная машина которая способна
> найти смысл почти в чем угодно, истолковать любой феномен, но
> совершенно не в состоянии принять мысль о непредсказуемости.
>

Re: Golang mudules to follow common grouping

[Sharlatan Hellseher]

Hi,

Part II of the split https://issues.guix.gnu.org/66827

Now we would have
- golang.scm - which would be logically keep on minimal number of packages
- golang-check.scm
- golang-web.scm - in review

Planed
- golang-crypto.scm
- golang-compression.scm
- golang-build.scm - which would include low level 0 dependencies packages.

I found a lot of golang packages in (gnu packages syncthing) which are not 100%
related to syncthing itself, possibly the were left there long ago.

Thanks,
Oleg

On Thu, 19 Oct 2023 at 10:40, Sharlatan Hellseher  wrote:
>
> Hi,
>
> I've accidentally included other patch to this series. I've re-sent it under 
> the
> new issue number https://issues.guix.gnu.org/66627.
>
> Thanks,
> Oleg
>
>
> On Mon, 16 Oct 2023 at 19:17, Sharlatan Hellseher  
> wrote:
> >
> > Hi,
> >
> > I'm about to create golang-check and golang-build modules, which both are 
> > core and would be in used by others. As Maxim mentioned, the most time 
> > consumption task would be migrating copyrights header properly.
> >
> > On Sun, 15 Oct 2023, 22:25 Wilko Meyer,  wrote:
> >>
> >>
> >> Hi,
> >>
> >> Sharlatan Hellseher  writes:
> >>
> >> > I think it's time to split (gnu packages golang) into some logical 
> >> > groups, see
> >> > Python, Lisp for example.
> >> >
> >> > Thoughts?
> >>
> >> IMHO this sounds like a good idea as it would improve the
> >> maintainability of golang packages in the long run. We have 487 package
> >> definitions right now:
> >>
> >> (~/devel/guix-devel/gnu/packages) λ rg -c 'define-public' golang.scm
> >> 487
> >>
> >> which already seems quite laborous to split into logical groups (while
> >> getting the copyright information right as well and maintaining the
> >> gitlog history etc.); so it probably classifies as a task that should be
> >> tackled sooner than later as it'll cause more work over time the more
> >> golang packages exist.
> >>
> >> --
> >> Kind regards,
> >>
> >> Wilko Meyer
> >> w...@wmeyer.eu
>
>
>
> --
>
> … наш разум - превосходная объяснительная машина которая способна
> найти смысл почти в чем угодно, истолковать любой феномен, но
> совершенно не в состоянии принять мысль о непредсказуемости.



-- 

… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.

Re: Golang mudules to follow common grouping

[Sharlatan Hellseher]

Hi,

I've accidentally included other patch to this series. I've re-sent it under the
new issue number https://issues.guix.gnu.org/66627.

Thanks,
Oleg


On Mon, 16 Oct 2023 at 19:17, Sharlatan Hellseher  wrote:
>
> Hi,
>
> I'm about to create golang-check and golang-build modules, which both are 
> core and would be in used by others. As Maxim mentioned, the most time 
> consumption task would be migrating copyrights header properly.
>
> On Sun, 15 Oct 2023, 22:25 Wilko Meyer,  wrote:
>>
>>
>> Hi,
>>
>> Sharlatan Hellseher  writes:
>>
>> > I think it's time to split (gnu packages golang) into some logical groups, 
>> > see
>> > Python, Lisp for example.
>> >
>> > Thoughts?
>>
>> IMHO this sounds like a good idea as it would improve the
>> maintainability of golang packages in the long run. We have 487 package
>> definitions right now:
>>
>> (~/devel/guix-devel/gnu/packages) λ rg -c 'define-public' golang.scm
>> 487
>>
>> which already seems quite laborous to split into logical groups (while
>> getting the copyright information right as well and maintaining the
>> gitlog history etc.); so it probably classifies as a task that should be
>> tackled sooner than later as it'll cause more work over time the more
>> golang packages exist.
>>
>> --
>> Kind regards,
>>
>> Wilko Meyer
>> w...@wmeyer.eu



--

… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.

Re: Golang mudules to follow common grouping

[Sharlatan Hellseher]

Hi Maxim,

I identified about 17 packages related to check/assert/mock/lint
process and moved them to (gnu packages golang-check)

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

Thanks,
Oleg

On Tue, 10 Oct 2023 at 04:52, Maxim Cournoyer  wrote:
>
> Hi,
>
> Sharlatan Hellseher  writes:
>
> > Hi Guix!
> >
> > I've noticed the number of Golang packages start growing. I expect more 
> > packages
> > to be reviewed and merged by quick check of Issues.
> >
> > I think it's time to split (gnu packages golang) into some logical groups, 
> > see
> > Python, Lisp for example.
> >
> > - golang-web
> > - golang-check
> > - golang-build
> > - golang-compression
> > - golang-crypto
> > - golang-xyz
> > - golang-...
> >
> > Thoughts?
>
> This sounds good to me.  Beware of correctly migrating the copyright
> lines though... these can be annoying to move.
>
> --
> Thanks,
> Maxim



-- 

… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.

Re: Golang mudules to follow common grouping

[Sharlatan Hellseher]

Hi,

I'm about to create golang-check and golang-build modules, which both are
core and would be in used by others. As Maxim mentioned, the most time
consumption task would be migrating copyrights header properly.

On Sun, 15 Oct 2023, 22:25 Wilko Meyer,  wrote:

>
> Hi,
>
> Sharlatan Hellseher  writes:
>
> > I think it's time to split (gnu packages golang) into some logical
> groups, see
> > Python, Lisp for example.
> >
> > Thoughts?
>
> IMHO this sounds like a good idea as it would improve the
> maintainability of golang packages in the long run. We have 487 package
> definitions right now:
>
> (~/devel/guix-devel/gnu/packages) λ rg -c 'define-public' golang.scm
> 487
>
> which already seems quite laborous to split into logical groups (while
> getting the copyright information right as well and maintaining the
> gitlog history etc.); so it probably classifies as a task that should be
> tackled sooner than later as it'll cause more work over time the more
> golang packages exist.
>
> --
> Kind regards,
>
> Wilko Meyer
> w...@wmeyer.eu
>

Re: Golang mudules to follow common grouping

[Wilko Meyer]

Hi,

Sharlatan Hellseher  writes:

> I think it's time to split (gnu packages golang) into some logical groups, see
> Python, Lisp for example.
>
> Thoughts?

IMHO this sounds like a good idea as it would improve the
maintainability of golang packages in the long run. We have 487 package
definitions right now:

(~/devel/guix-devel/gnu/packages) λ rg -c 'define-public' golang.scm
487

which already seems quite laborous to split into logical groups (while
getting the copyright information right as well and maintaining the
gitlog history etc.); so it probably classifies as a task that should be
tackled sooner than later as it'll cause more work over time the more
golang packages exist.

-- 
Kind regards,

Wilko Meyer
w...@wmeyer.eu

Re: Golang mudules to follow common grouping

[Maxim Cournoyer]

Hi,

Sharlatan Hellseher  writes:

> Hi Guix!
>
> I've noticed the number of Golang packages start growing. I expect more 
> packages
> to be reviewed and merged by quick check of Issues.
>
> I think it's time to split (gnu packages golang) into some logical groups, see
> Python, Lisp for example.
>
> - golang-web
> - golang-check
> - golang-build
> - golang-compression
> - golang-crypto
> - golang-xyz
> - golang-...
>
> Thoughts?

This sounds good to me.  Beware of correctly migrating the copyright
lines though... these can be annoying to move.

-- 
Thanks,
Maxim