Re: Golang mudules to follow common grouping

[Christina O'Donnell <cdo@mutix.org>]

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