-
Type:
Epic
-
Resolution: Won't Do
-
Priority:
Unknown
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Prevent import cycles and internalize packages
-
Done
-
0
-
0
-
0
-
100
-
None
-
None
Summary
Currently there are numerous cases where attempting to import a package causes an import cycle. Notable cases that cause import cycles are importing the x/mongo/driver/topology package in the x/mongo/driver package and trying to import the bson package from the bson/primitive package. As a result, there is a decent amount of unnecessary coupling via interfaces and odd functionality, like that stringifying a bson.D does not print ExtJSON.
Additionally, a lot of packages are importable by external projects despite the intended use case being strictly internal, such as the x/mongo/driver/uuid package or the mongo/integration/mtest package. These packages can be moved to an internal directory to prevent import by external projects.
Restructure the Go driver packages to minimize the probability of import cycles and internalize packages that aren't intended for use by external projects.
Note: Restructuring of all packages must be accomplished in a v2.0 driver; any restructuring before the v2.0 driver must be limited to packages in the x directory.
Motivation
Who is the affected end user?
Go driver devs and any external dev who imports packages they think are intentionally exported but are not maintained for external use by the Go driver team.
How does this affect the end user?
For Go driver devs, they have to do extra work, maintain unnecessary coupling between packages, and miss or re-implement code across packages when an import is not possible. For external devs, they may use code that is not intended for use outside of the Go driver and may encounter bugs or unexpected behavior.
How likely is it that this problem or use case will occur?
Import cycle problems are fairly common in the Go driver. Devs working on the x/mongo/driver and x/mongo/driver/topology packages run into them frequently.
It's not clear how many external projects import packages from the Go driver that should be internal.
If the problem does occur, what are the consequences and how severe are they?
Can make some code changes in the Go driver significantly more difficult and/or time-consuming.
Is this issue urgent?
No.
Is this ticket required by a downstream team?
No.
Is this ticket only for tests?
No.
Cast of Characters
Engineering Lead:
Document Author:
POCers:
Product Owner:
Program Manager:
Stakeholders: