Cthulhu: Organizing Go Code in a Scalable Repo

#1

Post by jsvcycling » Wed, Oct 11, 2017, 4:53 PM UTC

Cthulhu: Organizing Go Code in a Scalable Repo
blog.digitalocean.com

Re: Cthulhu: Organizing Go Code in a Scalable Repo

#2

Post by allengeorge » Thu, Oct 12, 2017, 12:19 AM UTC

Hmm. Sounds like “gta” is a reimplementation of “pants” or bazel (? - I’ve never worked with bazel).

Re: Cthulhu: Organizing Go Code in a Scalable Repo

#3

Post by bovermyer » Thu, Oct 12, 2017, 2:05 AM UTC

Nothing good can come of naming a project `cthulhu`.

Re: Cthulhu: Organizing Go Code in a Scalable Repo

#4

Post by NightMKoder » Thu, Oct 12, 2017, 3:56 AM UTC

allengeorge wrote: post #2

Hmm. Sounds like “gta” is a reimplementation of “pants” or bazel (? - I’ve never worked with bazel).

I think they have a similar goal. The difference sounds like gta uses git for change detection while bazel uses hashes to detect changes (hashes include the hashes of the transitive closure of the deps; it’s a dag). The latter is more robust in the face of noop edits that don’t change the output as well as distributed caching of test/build results.

Re: Cthulhu: Organizing Go Code in a Scalable Repo

#5

Post by pdfernhout » Thu, Oct 12, 2017, 4:23 AM UTC

bovermyer wrote: post #3

Nothing good can come of naming a project `cthulhu`.

It sort of "worked" for Lovecraft :-) even as people may suggest other actions and alternative interpretations of the human situation:

"H.P. Lovecraft Invented a Horrific World to Escape a Nihilistic Universe" https://newrepublic.com/article/119996/hp-lovecrafts-philoso...

Re: Cthulhu: Organizing Go Code in a Scalable Repo

#6

Post by [deleted] » Thu, Oct 12, 2017, 5:13 AM UTC

bovermyer wrote: post #3

Nothing good can come of naming a project `cthulhu`.

[deleted]

Re: Cthulhu: Organizing Go Code in a Scalable Repo

#7

Post by donatj » Thu, Oct 12, 2017, 5:30 AM UTC

I understand the theory behind Monorepo but it always just rubs me the wrong way.

Re: Cthulhu: Organizing Go Code in a Scalable Repo

#8

Post by captaindiego » Thu, Oct 12, 2017, 6:33 AM UTC

A little off-topic, but does anyone have any recommendations for methods for managing 10s of git repos as various dependencies for wildly varying projects as opposed to this sort of mono-repo approach? I've seen some organizations try to use ivy, but never in a robust way.

Re: Cthulhu: Organizing Go Code in a Scalable Repo

#9

Post by qznc » Thu, Oct 12, 2017, 7:32 AM UTC

donatj wrote: post #7

I understand the theory behind Monorepo but it always just rubs me the wrong way.

I find them appealing because orchestrating lots of git repos is such a mess.

Re: Cthulhu: Organizing Go Code in a Scalable Repo

#10

Post by vvvrrooomm » Thu, Oct 12, 2017, 9:07 AM UTC

qznc wrote: post #9

donatj wrote: post #7

I understand the theory behind Monorepo but it always just rubs me the wrong way.

I find them appealing because orchestrating lots of git repos is such a mess.

IMO the solution is git submodules. The problem with submodules mostly is the horrible workflow and the missing tool integration. Varying dependencies could result in separate parent repos that contain different subsets of submodules. A simple script can fix tooling: first commit the submodule changes then create the parent repo commit.