I concur with the approach of having a single module for the driver, I don't think this project is complicated enough yet to require separate modules, the project is new to the Apache foundation and keeping things simple will make it easier for people to learn and contribute.
I also agree that we need to look at moving lz4 from its own module into the gocql module as a package. I think that it makes sense to do this to remove the circular dependency, we really shouldn't ever be in the situation where we have that happening, at best it'll look odd to people paying attention, but it'll probably lead to headaches later on if we leave it. Probably best to do that before cutting a 2.0.0 release? On Fri, Nov 8, 2024 at 2:55 AM João Reis <joaor...@apache.org> wrote: > The goal of CASSGO-21 [1] is to move HostPoolHostPolicy out of the main > package so that users don't have to download the > github.com/hailocab/go-hostpool dependency if they are not using this > specific policy. > The question is whether we want to move this policy to a separate module > or if it is enough to move it to a separate package on the same module. > There is currently an open PR for this issue that uses the separate package > approach [2]. > > The way we choose to resolve CASSGO-21 should dictate what we do in the > future for similar "extension" like code. For example, the PR [4] for > CASSGO-9 [3] adds 2 "extensions" that provide out of the box functionality > to use the logging libraries "zap" and "zerolog" with gocql and these are > implemented in their own independent modules that are located in an > "extensions" folder of gocql's repository. > > Lz4 support is also implemented as an independent module at the moment and > as part of CASSGO-1 (protocol v5 support) we need to run the integration > test suite with lz4 compression since snappy is not supported in protocol > v5 but this creates a circular dependency between "gocql/go.mod" and > "gocql/lz4/go.mod". For context, CI only uses snappy compression on > integration tests at the moment. The circular dependency might be ok since > its usage in the "gocql" package is limited to "_test.go" files, but it > doesn't look great. > > In summary, I think we should either move HostPoolHostPolicy to a new > module or we should consider making "gocql/lz4" a package instead of a > module and changing CASSGO-9's patch so that zap and zerolog support is > also implemented in separate packages instead of modules. > > In my opinion we should use packages within the main "gocql" module for > this instead of separate modules (at the very least for > "HostPoolHostPolicy" and "lz4"). Separate modules could make sense when we > want to independently version and release a particular "extension" but in > my opinion I don't think we have that requirement for the specific use > cases that I've mentioned so far. > > [1] https://issues.apache.org/jira/browse/CASSGO-21 > [2] https://github.com/apache/cassandra-gocql-driver/pull/1770 > [3] https://issues.apache.org/jira/browse/CASSGO-9 > [4] https://github.com/apache/cassandra-gocql-driver/pull/1755 > [5] https://issues.apache.org/jira/browse/CASSGO-1 >
