Move `compas_blender`, `compas_ghpython`, `compas_rhino` to their own repos

[chenkasirer]

To better manage dependencies and ease updating documentation.

[gonzalocasas]

In principle, the idea is nice, but there's one important note to consider: splitting repositories will create a dependency tree that is harder to manage. The different projects will be able to evolve independently, which means that there's gonna be a big set of possible combinations of core + compas_rhino that can be installed by users and will go untested. The way this is usually tackled in large projects is with automated testing. The biggest problem is that the CAD packages (compas_rhino, compas_blender and compas_ghpython) are not unit testable, so there will be no safety net for broad changes that affect stuff across the board, because it will be impossible to test older compas_rhino releases against newer compas core ones.

In the end, this might result is us forcing a pseudo-pairing of these packages by carefully taking care of the dependency taken on compas core. It's not clear to me if this will really work. I imagine something like the CAD packages limiting the upper bound version to the current know major and minor, so that a bump of minor on core will stop the installation if there's no newer release of the CAD package that explicitly supports that.

I know this comment can be read as pretty negative of the idea. It's not really the case, from a software engineering point of view, I like the smaller package approach, I'm just worried about the impact on maintenance, but if we can find a pragmatic solution for it, then the underlying idea of splitting up things sounds good.

[jf---]

when trying to round off your nuanced answer @gonzalocasas to 0 || 1 this reads like a close plz

but to address @chenkasirer fair point: the submodule need to be substantial enough to warrant the friction of yet another repo to maintain.

Whether a modest topical micro repo vs a Why Google Stores Billions of Lines of Code in a Single Repository is applicable is not a hard science.

submodules are nice in theory, but can be (a lot more) challenging to handle

[tomvanmele]

for me, the main reason to split them off is that it removes the impression that compas requires these softwares in order to be used. i see compas_rhino, compas_ghpython, compas_blender, like compas_viewer, merely as some of the environments where compas CAN be used.

ideally, in the future there will be many more of those and then it would make more sense to me if none of them are directly included in the core codebase.

as for the testing, currently we don't have a good way to test compas_rhino, compas_ghpython and compas_blender anyway so perhaps we could develop one as pat of moving them to their own repo. this might make testing them also a lot easier...

[jf---]

Testing is a strong argument and keeping compas core nimble.

Should be fairly straightforward to factor out and keep an umbilical chord via git submodules?

Those modules go back to the early days so keeping the folder layout intact via submodules makes sense I feel.

[tomvanmele]

Those modules go back to the early days

haha, to me that almost sounds like a very good reason to kick them out :)

[jf---]

@tomvanmele in summary:

• split of in modules
• setup a branch of compas and link the newly created branches as git submodules?

[tomvanmele]

i don't see the point of git submodules in this context. i also don't think the concern of @gonzalocasas is related to keeping the repos synced, but rather the individually released packages. i guess this can be solved by proper management of the corresponding requirements files...

perhaps this was not entirely clear from my earlier argumentation, but i think compas, compas_rhino, compas_blender, ... should just be individual Python packages with their own repos that are linked like all other Python packages by specifying matching versions in their requirements files.

[jf---]

i don't see the point of git submodules in this context

dampen the shock of the news, in github, a submodule will link to the repo directly, its highly ergonomically. moreover, when checking out the compas codebase, submodules will come along. it makes the evolution of the codebase somewhat more gradual.

since its little effort to set up, it might be worth examining it in a separate branch.

linked like all other Python packages by specifying matching versions in their requirements files

for installation, sure.

[yck011522]

I think what should be clarified is whether core developers intend to maintain the CAD code at the same pace as the core release.

At the moment with a unified repo, or in the case of a submodule relationship, the CAD code must (are forced to) be updated at the same time as core updates. In the case of a plugin, the can be out of sync.

Benefit of keeping sync is clearly the fact that all CAD software can enjoy the latest core, all the time, because the developers are forced to update it.

Benefit of not keeping sync is probably the fact that developers can release core first and update a certain CAD later. Downside is clearly more dependency hell for the user to maintain their code.

[gonzalocasas]

@yck011522 very well summarized

All things considered, I'm leaning towards keeping this together in a unified repository for the time being.