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-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

On Monday, December 16, 2024 at 11:31:27 AM UTC-5 Doug Fawley wrote:

> 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.
>
> On Friday, December 13, 2024 at 9:15:06 PM UTC-8 Sean Liao wrote:
>
>> 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
>>
>> On Sat, Dec 14, 2024, 13:37 'Doug Fawley' via golang-nuts <
>> golan...@googlegroups.com> wrote:
>>
>>> 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
>>>
>>> -- 
>>> 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
>>>  
>>> <https://groups.google.com/d/msgid/golang-nuts/3103aade-0d28-4274-a83e-3d947485f650n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/golang-nuts/061865a9-7238-4169-b0b4-fcf668b659bdn%40googlegroups.com.

Reply via email to