Removing a module from a multi-module repository

[Doug Fawley]

The following section indicates that it should be possible to safely remove a module from a multi-module repository, and move the removed module's packages to the parent module:

https://go.dev/wiki/Modules#is-it-possible-to-remove-a-module-from-a-multi-module-repository

However, it doesn't say how to accomplish this.

To add a new submodule, the steps are clear:

1. Create the new module

2. Add a dependency on the new module to the parent module

When merging two modules, however, there is no way to add a dependency to the deleted submodule to refer users to the parent module, and there is no way to refer to a deleted version of the submodule from the parent module.  This results in an ambiguous import if one module in a project refers to the parent module at the new version and another module in the same project refers to the deleted submodule at an older version.

I had wrongly assumed that if a newer version of the parent module included the package, that it would replace the version in the submodule, but I now see why that is wrong.  But I still don't know how to address the issue.  Is there some way to add an entry in the parent go.mod that indicates that the submodule was deleted?

In case it's relevant, the submodule that was removed in this instance was unstable (v0).  But we still don't want to break users that were using it, since the API didn't change when we incorporated it into the parent module and released it as stable.

The specific incident is being tracked here: https://github.com/googleapis/google-cloud-go/issues/11283

Thanks,

Doug

[Sean Liao]

There's no automatic upgrade path, the best you can do is mark the sub module as retracted and/or Deprecated. your users will need some manual action to drop it as a dependency.

- sean

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/3103aade-0d28-4274-a83e-3d947485f650n%40googlegroups.com.

[Doug Fawley]

If that's true, then I think the wiki should be updated with a better description, shouldn't it?  The implication is that it is safe and just the reverse of adding a sub-module, but it doesn't sound like that's the case at all.  Is it okay to do if a v1+ release has happened?  And in our case, we have no releases to retract -- the go.mod referencing it just specifies its version as a hash.

Is there a way to `exclude` the sub-module?  We tried to do something with that, but we weren't able to make it work.

[thepud...@gmail.com]

Hi Doug,

Consider this a drive by comment, but you might be able to create a version of the nested module that does not have any code in it, and set up a requirement cycle between the nested module and a new parent version. 

I think there’s a general approach of creating a requirement cycle for a removed modules within a repo so that any consumer that points to one of the module in the repo automatically gets ratcheted forward to a consistent version of the other module within that same repo.

In the past, I’ve helped some open source projects work through similar issues, including for example you can see the comments I wrote here a while ago to help ugorji/go/codec to deal with ambiguous import errors for many consumers because the same package appeared in two modules (including writing some testscript tests to verify expected behavior):

https://github.com/ugorji/go/issues/299#issuecomment-495465786

https://github.com/ugorji/go/issues/299#issuecomment-495793804

https://github.com/ugorji/go/issues/299#issuecomment-496468760

Caveats include your situation might be different, and also the last time I did this on a real repo with many open consumers was before the introduction of module pruning, which could have changed things, but I haven’t pondered that too much. 

In any event, something to consider, and of course you’d want to test to convince yourself if it would work or not for you. 

Best regards,

thepudds