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 <https://pkg.go.dev/golang.org/x> 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
