Support for git submodules

[olof-dev]

Use case

I'm using the git: functionality of pubspec.yaml to depend on a package distributed via a git repository. That repository consists of a Flutter plugin that uses native code, with the native code placed in the plugin's ios directory. This native code is itself a library, coming from external sources, and the natural way of doing version control seems to be to include it as a git submodule in the plugin's repository.

Being a submodule, its code doesn't get automatically pulled in when the plugin repository is cloned, meaning that the plugin pulled in by pub doesn't include the native library. Would it be possible to offer the option for pub to recursively pull in submodules?

Changes needed

The relevant command is probably

git clone --recurse-submodules

Perhaps one can offer syntax like

dependencies:
  my_package:
    git:
      url: https://github.com/username/repo_name.git
      recurse-submodules: true

Workarounds

One can of course move the submodule to another location and copy the files across to the plugin directory, but this is far from ideal. I'm not sure if there's a better method. Iirc git doesn't like symlinks.

Edit: I just discovered git subtrees. I think they can also be used as a workaround, though they seem a lot less convenient than submodules.

[sigurdm]

I can see how this can be useful.

Similar to the recent request for git lfs support #1433.

I worry about having features with just a few users and wonder how widespread the use of submodules is.

Please upvote if you would like this feature.

[p4-k4]

Voting for this.

[JoseGuilhermeCR]

It should definitely be doable... I don't want to develop a "native" library under a flutter plugin repository... git submodules work great, they should've been used from the start.
I'll just place a condition on the flutter devs, they will need to copy the folder manually since flutter itself can't seem to do it 🤷

[rjhind]

We need this too. We have C processing code pulled in to a plugin as a submodule and it would be much more useful to have the flutter pub get do a submodule update.

[PeteClubSeven]

This also would've been helpful to me, I can imagine a lot of FFI use cases will desire this.

[iulian0512]

+1

[ghost]

any news on this?

[sigurdm]

any news on this?

No news currently

[bvnp43]

Is this something hard to implement, jesus, 4 yo issue.

There is a cmake function FetchContent_Declare that allows to fetch sources during build stage - workaround for platforms that use cmake build system.

[olof-dev]

To everyone who wants this, make sure you thumbs up the initial post.

Has anyone thought through potential security implications? I don't really see this being used for anything than one's own git repositories, but it's probably best to think about whether it could be misused. Could it potentially lead to the download of unexpected (potentially malicious) code? I.e. is it possible that a user would look at the code in the head git repository, determine it as safe, but miss looking at code in a submodule? It doesn't seem particularly likely, and even if so, one could make it clear as part of the flag (recurse-submodules: true) that one should be security conscious.

[PeteClubSeven]

We can already download unexpected and potentially malicious code even in packages published on pub.dev. You can run cmake and script files as much as you want for Apple platforms and Android (not sure about Windows/Linux/Web). I am however all for transparency, for example if a package uses a submodule having that printed to the output log would be a good idea imo if that's the concern.

Edit: I've added a thumbs up as you suggested but when I see an issue like this, especially an old one, it's quite discouraging and I don't expect we'll see this change.

[ipr-fredrik2]

This seems like a no-brainer.

Any comment from devs?

[ipr-fredrik2]

I've pushed a PR for this, as an example of a very simple solution to this problem (always recurse submodules when cloning git packages)

I'm not sure who can see it though, since apparently I need to nag the CEO of my company to sign a legal document in order to properly file this PR.

This seems like a huge effort given that the fix is like 12-13 letters or something.

If any existing contributor sees this and just wants to add this change, I would be forever grateful.

See b44f490

[Levi-Lesches]

Another use-case: many Flutter FFI plugins are simply wrappers around pure Dart FFI libraries until Native Assets are released on stable. In turn, many of these pure Dart FFI libraries are wrappers around a 3rd party SDK or library. So you might find a Flutter library that looks like:

3rd party C/C++ library --> Dart FFI plugin + ffigen --> Flutter FFI plugin + compilation instructions

See: flutter_libserialport and flutter_sdl_gamepad (my own). These plugins should be using submodules for the 3rd party native code but can't, and must commit and push everything manually for Pub to include it. This means we can't use the traditional methods to express "we are not the authors of this library, here is the original repository, here is the exact commit we used, and run this command to get a later version".

(Even in non-Flutter contexts, I'm not sure if native assets will be able to handle this case).

[melWiss]

any news on this?