Drivers as submodules

[vascotenner]

I think that the most 'git' way of organizing this repository, is to create a repository for every brand (or even brand_device) and link this repositories to this one via a git submodule.

[MatthieuDartiailh]

I am not very familiar with git submodules. Could you elaborate a bit on how this would simplify the management of the project. I fear It will confuse people with respect to bug report.

[vascotenner]

One of the reasons is that this would allow to develop on several drivers at the same time, with all their own branches. Furthermore, the git log is cleaner and less merging is needed. This makes it easier for unexperienced git users (like me) to contribute.

Bug reports should be published best in the bugtracker of the repo of the driver.

[bilderbuchi]

In my experience with Git, this would work and I guess be clean, but quite confusing - you'd pollute your organisation with O(10-100) repositories just to isolate different brands of devices, and would "gain" synchronization/browsing/commit history reading issues in the process.

I have to admit I don't fully understand, why does having one repo stop you from develop separate drivers in separate branches, and how do submodules fix that?

[vascotenner]

Quite often, I am developing several drivers at the same time. For every driver I like to have a separated branch, to keep the log messages and history separated. It is very easy to go back to an older version.

However, with git I cannot create a branch for only a specific subdirectory, only for the whole repository. When I am working in branch for driver "A" and i want to add something to driver "B", I have to first checkout branch "B". But at that moment, I cannot access the newest version in driver "A".

Another example might be a pull request: I have been developing A, B and C. I want to add A to the labpy repositry, but not B and C, because they are in a alpha stadium. With a single branch with all three drivers in them. it is hard to create a clean pull request. When these drivers live in seperate submodules, they all have their own repository and can be easily merged.

One question remains: on what level should the submodules live? One repository for one manufacturer? Or one per manufacturer/device type (thorlabs for example, sells both motion controll devices, optical powermeters, laserdrivers).

A bigger concern in the labpy repository is the lack of activity in the last years. There are some forks that have many new drivers, there are quite some PRs but they are not approved.

@hgrecco: What are your plans with the labpy organization? Can you add more developers to this group such that things will start running again?

[bilderbuchi]

For this kind of parallel development, check out git worktree https://git-scm.com/docs/git-worktree https://spin.atomicobject.com/2016/06/26/parallelize-development-git-worktrees/. I have not personally needed that yet, but have run across it a couple of times in the past.

Also, I caution that as soon as these changes you propose spill outside of your driver "A" subfolder (i.e. if you need to change the Readme, setup.py, or other file in the main repo, you suddenly have to take care of two pull requests against two different repos (main and driverA), which should be reviewed, tested, and merged synchronously. That's probably gonna cause a couple of headaches.
Same with coordinating issues across repos. One tracker for all things is actually a good thing. You can organise/subdivide as needed using issue labels quite nicely.

With a single branch with all three drivers in them. it is hard to create a clean pull request. When these drivers live in seperate submodules, they all have their own repository and can be easily merged.

The first sentence is a hard requirement to meet (and I don't understand the need for that, tbh). If you had 3 different branches as normal, clean PR and easy merge are not problematic. If the changes are largely independent, merging them one after another also won't be a problem

A bigger concern in the labpy repository is the lack of activity in the last years.

Yeah, there's that. As long as nobody brings in new stuff at a fast clip, it's a probably a bit moot/premature to discuss this. In my opinion (based on experience managing a large-ish repo with many contributors), submodules are probably not the best way to structure this.

I don't want to be dismissive of your input at all(!), but I'd rather avoid the submodule management headaches I have experienced in the past and prefer to help you with your git workflow to achieve smooth operations for you. :-)

[vascotenner]

Thank you for the link to git worktree. This is exactly where I was looking for.

I now agree that a single repository containing all the drivers is a good idea.

[bilderbuchi]

Great! 😁
Somebody with permissions can close this issue.