Monorepo

[Tuller]

Here's my proposed layout. I checked out the commit immediately before the merge on master and did a subtree merge of OmniCC_Config (before commit that wiped out all of the files) into a sub directory. If we were to use this going forward I would probably force push this to master.

Benefits

• The configuration UI remains as a separate addon, and is therefore is only loaded if the user happens to do configuration.

Drawbacks:

• You can't simply do a git clone OmniCC to your addons directory. For me, I've opted to wrap the bigwigs packager script to publish locally and auto adjust the TOC for classic/retail.

[Jaliborc]

I personally have a few issues with this approach. Just my humble opinion, but I see several drawbacks and little to no advantages.

Drawbacks:

• As you pointed out, we can't have the repo in the addons folder.
  • This means we need to have two local copies of the addon at all times, the one in the Addons folder, and the one in the repo.
  • We also need to either manually copy the changes each time to the actual repo, or have an additional program that does it (like your BW script).
  • We also need to backwards update the one in the Addons folder when pulling. The more libraries, the worse it gets too.
  • While working on the Addons folder, IDEs cannot track the changes we made thus far to the addon.
• In my case, this is also incompatible with my uploader.

Advantages

• The only advantage is that OmniCC_Config.toc is included in the repo (a file which the only change tends to be the TOC number).

P.S: I'm probably wrong here, but I am under the impression that you might believe my proposed change in the repo makes Config not Load on Demand. Just in case of that I will clarify: Config is still LOD. The OmniCC_Config/OmniCC_Config.toc file is loaded on demand as before. It then loads OmniCC/config.xml, which contains all the actual files originally in OmniCC_Config. This makes latter changes to the files being loaded part of the repo and minimizes changes to the .toc file. All the files listed in config.xml were not loaded by OmniCC, and thus are only loaded when OmniCC_Config is.

In conclusion, I still prefer the merged option, as it makes no changes to the existing pipeline, and thus working for both of us, while still having all the code in a single repo. The only disadvantage is that this repo doesn't track OmniCC_Config/OmniCC_Config.toc.

What do you think?

[Tuller]

Weird, it’s surprising to me that you can load files outside of your own addon.

[Jaliborc]

.toc files work with relative paths. So you can just ..\OtherAddon\myfile.lua if you want.

I tried it for the first time a couple years ago. Was mind blown it worked at all too.

[Jaliborc]

So, what is your opinion on either approach?

[Tuller]

I still like mine due to the aforementioned auto toc adjustments for classic/retail with the packager, but I'll survive.