feature request: failing a build that must have only a single version of a package

[glycerine]

Go v1.24, any platform.

In the context of shutting down goroutines,
my idem package used to use multiple mutexes, one within each
struct object IdemCloseChan and Halter. For reference,
https://github.com/glycerine/idem/blob/master/halter.go
is the implementation.

However when using trees to coordinate shutdown between
a lead package and a sub-package, I encountered alot of
deadlock issues due to different lock acquisition orders.

Therefore I arrived at the simple, perhaps crude, but effective
remedy of using a single mutex in the idem package for
all locking. The synctest document's discussion of
why mutexes are ignored indicated that
the Go standard library commonly does the same
for caches.

However I realized today that the Go build process allows
multiple versions of the same package to be included
in the final binary. This would re-introduce the two lock
ordering problem which I am seeking to avoid in
some cases, and might even violate mutual exclusion in others.
The runtime has the luxury of knowing it is the only
instance of the runtime, but user packages have
no such guarantee; I believe.

Questions:

a) is there a way to mark a package, such that the build
will fail if it includes two different versions of the same package?
After searching, I could not find such a facility.

b) Failing that, is there a way that a package itself can detect
and remedy the situation at runtime? Maybe it could read through the lately
included package manifests by some reliable API? I am
a bit loathe to run strings on the final binary and hope
the format of the BOM does not change or get compressed over time.

If either such exists, please point me towards it.

Conclusion: if (b) exists but is the only means available today,
please consider this a feature request for
an (a) mechanism, with the rationale fully laid out above.

To elaborate, build processes should be able to eagerly detect and fail builds
that will always crash themselves for safety at runtime anyway.

Thank you.

[Merovius]

For visibility, reproducing some of my responses from the golang-nuts thread

is there a way to mark a package, such that the build will fail if it includes two different versions of the same package? After searching, I could not find such a facility.

No, and that is by design. If module A and B would be mutually exclusive, you can end up with a module dependency graph of E->C->A and E->D->B. Importantly, that can happen after a minor version bump of (say) module D: Perhaps D had a security issue and the fix required an import of B. That means module E can not upgrade to the fixed version of module D, without breaking their build. And they can not make either module C or module D change their imports in a timely manner (if we assume that the modules are maintained by different entities, e.g. in the open source world).

Avoiding these kinds of situations was a major design goal of Go modules.

Failing that, is there a way that a package itself can detect and remedy the situation at runtime?

It is possible to read a list of included modules via runtime/debug (though that has limitations as well). However, I advice strongly against that. Because the reasoning for not making this possible statically still exist when doing it at runtime. Except that if you do it at runtime, that situation will only get exposed once the binary is built and potentially deployed.

I think you really just should not have packages which can not be mutually included with another package. I haven't looked at your package in particular. But I'm really confused how that can even be. Because after all, couldn't you also have a third party do similar things then, and that break your package? In general, Go tries hard to avoid that kind of stuff.

[glycerine]

I appreciate the comprehensive advice, Axel. I'll close this out since it seems to be an anti-pattern for reasonable reasons.

[glycerine]

For anyone else finding this with the same question, the critical advice is to prevent the problem from ever arising -- by keeping the mutex in an ultra stable, never changing v1 internal-style package. Axel explains it better, with more detail, in his list reply, which I quote here for ease of reference:

The only case where you can reasonably say that there are "two versions of the same package" in a build, is if they are in different major versions of the same module¹, say example.com/foo/v2 and example.com/foo/v3.

In that context, you have control over both versions. You can guarantee that they use the same mutex, by having them refer to each other. That is, you would implement v2 in terms of v3, that way ensuring that even if some code still imports v2, they still ultimately use the v3 mutex.

However, there is a problem: You can only implement v2 in terms of v3, once that exists. So you might introduce v3 while v2.23 is out and then have to introduce v2.24 to be implemented in terms of v3. But some clients might still import an v2.23. If those builds than also add v3, you end up with two mutexes.

The way around that is to have both of those refer to a third package, which contains the mutex. So you would have example.com/internal/mutex (which lives in its own module example.com/internal) which contains a mutex and have example.com/foo/v...@v2.24 import that to refer to the mutex. You can then wait until all importers have upgraded to v2.24. And when you then build example.com/foo/v3, it also imports example.com/internal/mutex. That way, all builds use a single mutex.

Of course, there is still a rest risk of clients not upgrading from v2.23 at all. But unfortunately, if you can't somehow prepare the earlier version and rely on that preparation to propagate, you are out of luck, I believe.