Oolite Bulletins

another_commander wrote: ↑Sat Aug 02, 2025 5:12 pm

The reason is mentioned at the end of the Readme.md:

So oolite .gitmodules allows forks to use their own versions of the submodules ?
Especially for 3rd party submodules (mozilla js, vorbis , ogg ) that seems unusual.

Lone_Wolf wrote: ↑Sat Aug 02, 2025 5:35 pm

So oolite .gitmodules allows forks to use their own versions of the submodules ?

Not entirely sure as I never encountered any issues myself, nor did I have to build from a cloned fork, but what is described in the readme has happened in the past, hence the action to mitigate any potential problems.

Lone_Wolf wrote: ↑Sat Aug 02, 2025 5:35 pm

another_commander wrote: ↑Sat Aug 02, 2025 5:12 pm

The reason is mentioned at the end of the Readme.md:

So oolite .gitmodules allows forks to use their own versions of the submodules ?
Especially for 3rd party submodules (mozilla js, vorbis , ogg ) that seems unusual.

It has to. How else would you develop stuff that requires changes to the submodules?
Or the other way round: how would you maintain the submodules without being able to test them in the full project?

I'd make the absolute paths the defaults and advise those that need to test local/other versions of submodules to override that.

Currently the local submodules are the default and the absolute urls the exception.
To me this gives the impression that the local versions are deemed more important then the absolute versions.

It is possible that this comes from differing point of views. Mine is that of a user / downstream packager, not of a developer.

I would like to ask a basic question: are submodules necessary? Could we for example use a monorepo or possibly package management (eg. GitHub itself can house build artifacts)?

The reason I ask is in case there might be a simpler way to organise the project particularly after MrFlibble's changes, including removing things that are obsolete, are merged.

There is much debate about the usage of submodules these days eg.

"In my experience, git submodules combine the worst of monorepos and multirepos. I get the idea. You want to separate independent or shared parts of the project into separate repos for a clean architecture and separation of concerns. But then why not go all they way and manage the dependencies with a proper package manager? Just publish the library projects to an internal package repository and pull them in the dependant repo. Often, especially in smaller projects or teams, the extra overhead is not worth it. You want to be able to work on multiple of these projects in tandem and iterate quickly. So you use submodules, because that's almost as if it was all in a single repo. But then why not go with a monorepo?"

"During my last 8 years working in dev teams, DevOps teams and plain ops teams, using Submodules always resulted in chaos, to the point that all projects abandoned submodules and added linters that forbid adding submodules"

mcarans wrote: ↑Mon Aug 04, 2025 8:52 pm

"During my last 8 years working in dev teams, DevOps teams and plain ops teams, using Submodules always resulted in chaos, to the point that all projects abandoned submodules and added linters that forbid adding submodules"

I've had such 'fun' wrangling the submodule with git. Mercifully it was the submodule that suffered frequently from a detached head

Hopefully someone will clarify the point of the submodules in Oolite source. Surely they've remained in use here for so long for a good reason?

MrFlibble wrote: ↑Mon Aug 04, 2025 10:29 pm

mcarans wrote: ↑Mon Aug 04, 2025 8:52 pm

"During my last 8 years working in dev teams, DevOps teams and plain ops teams, using Submodules always resulted in chaos, to the point that all projects abandoned submodules and added linters that forbid adding submodules"

I've had such 'fun' wrangling the submodule with git. Mercifully it was the submodule that suffered frequently from a detached head

Hopefully someone will clarify the point of the submodules in Oolite source. Surely they've remained in use here for so long for a good reason?

I can imagine that it wasn't much fun dealing with that. I expect it is simply inertia that has kept things unchanged all this time. In the beginning maybe multiple developers were iterating simultaneously in both submodules and main code, so there may have been some benefit but now those submodules are not touched so much and submodules get in the way, it would be good to simplify.

NB: I've noticed it is possible to change the subject in a reply on this BB and have done so for this one. Is that the right thing to do if the topic shifts?

mcarans wrote: ↑Wed Aug 06, 2025 10:39 pm

I've noticed it is possible to change the subject in a reply on this BB and have done so for this one. Is that the right thing to do if the topic shifts?

YES.

mcarans wrote: ↑Wed Aug 06, 2025 10:39 pm

NB: I've noticed it is possible to change the subject in a reply on this BB and have done so for this one. Is that the right thing to do if the topic shifts?

As per Wildeblood above.

Further - the chap who started the thread can go back and edit the title on his first post to include any relevant red herrings which were introduced.