4 ms·

Cthulhu: Organizing Go Code in a Scalable Repo

111 points by jsvcycling 9y ago

allengeorge 9y ago
Hmm. Sounds like “gta” is a reimplementation of “pants” or bazel (? - I’ve never worked with bazel).
- NightMKoder 9y ago
  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.
bovermyer 9y ago
Nothing good can come of naming a project `cthulhu`.
- pdfernhout 9y ago
  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-philosophy-horror https://newrepublic.com/article/119996/hp-lovecrafts-philoso...
- deleted 9y ago
  [deleted]
- Cthulhu_ 9y ago
  oi
  - bovermyer 9y ago
    Note I said "project." How's R'lyeh these days?
donatj 9y ago
I understand the theory behind Monorepo but it always just rubs me the wrong way.
- qznc 9y ago
  I find them appealing because orchestrating lots of git repos is such a mess.
  - vvvrrooomm 9y ago
    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.
    - qznc 9y ago
      You don't want to create a commit in the parent repo all the time. If you fix a typo in a comment in a submodule, why commit anything to parent? Anyways, which parent, since there can be many. There should be more than one. Otherwise why use a submodule? Another problem is that one forgets to update submodules when switching branches. Afaik git does not do this because of possible data loss in submodules? I like submodules in general. They are great for dependencies where you want to follow more closely than release version. Still, it would be even easier in a monorepo. The main reason is probably that every anti-dependency is visible.
- hasenj 9y ago
  Why? Because it doesn't follow the dogma of compartmentalizing everything for "maximum reusability"?
- jacques_chester 9y ago
  Once you realise that the reason you can't find the critical production code that's fritzing is because it's in another goddamn repo you didn't know about, you become a fan. Having to reverse engineer CI/CD (or find someone who used to work on a project) to find where something came from is nuts. It should be as easy as search.
captaindiego 9y ago
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.
al2o3cr 9y ago
IA IA IF ERR != NIL FTAGHN
- Cthulhu_ 9y ago
  H̸̡̪̯ͨ͊̽̅̾̎Ȩ̬̩̾͛ͪ̈́̀́͘ C̷̙̲̝͖ͭ̏ͥͮ͟Oͮ͏̮̪̝͍M̲̖͊̒ͪͩͬ̚̚͜Ȇ̴̟̟͙̞ͩ͌͝S̨̥̫͎̭ͯ̿̔̀ͅ

111 points by jsvcycling 9y ago

allengeorge 9y ago

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

NightMKoder 9y ago
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.

bovermyer 9y ago

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

pdfernhout 9y ago
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-philosophy-horror https://newrepublic.com/article/119996/hp-lovecrafts-philoso...
deleted 9y ago
[deleted]
Cthulhu_ 9y ago
oi
- bovermyer 9y ago
  Note I said "project." How's R'lyeh these days?

donatj 9y ago

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

qznc 9y ago
I find them appealing because orchestrating lots of git repos is such a mess.
- vvvrrooomm 9y ago
  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.
  - qznc 9y ago
    You don't want to create a commit in the parent repo all the time. If you fix a typo in a comment in a submodule, why commit anything to parent? Anyways, which parent, since there can be many. There should be more than one. Otherwise why use a submodule? Another problem is that one forgets to update submodules when switching branches. Afaik git does not do this because of possible data loss in submodules? I like submodules in general. They are great for dependencies where you want to follow more closely than release version. Still, it would be even easier in a monorepo. The main reason is probably that every anti-dependency is visible.
hasenj 9y ago
Why? Because it doesn't follow the dogma of compartmentalizing everything for "maximum reusability"?
jacques_chester 9y ago
Once you realise that the reason you can't find the critical production code that's fritzing is because it's in another goddamn repo you didn't know about, you become a fan. Having to reverse engineer CI/CD (or find someone who used to work on a project) to find where something came from is nuts. It should be as easy as search.

captaindiego 9y ago

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.

al2o3cr 9y ago

IA IA IF ERR != NIL FTAGHN

Cthulhu_ 9y ago
H̸̡̪̯ͨ͊̽̅̾̎Ȩ̬̩̾͛ͪ̈́̀́͘ C̷̙̲̝͖ͭ̏ͥͮ͟Oͮ͏̮̪̝͍M̲̖͊̒ͪͩͬ̚̚͜Ȇ̴̟̟͙̞ͩ͌͝S̨̥̫͎̭ͯ̿̔̀ͅ