I don't think introduce sqlflow in this repo is a good idea. pysqlflow shouldn't depend on sqlflow, since sqlflow are already depending on pysqlflow.

If we want to upgrade the service protocol, we can

1. sqlflow: Use a fix version of pysqlflow at sqlflow's Docker image https://github.com/sql-machine-learning/sqlflow/blob/develop/scripts/image_build.sh#L37 like sqlflow==0.1.0
2. pysqlflow: Update pysqlflow's service protocol. Make all tests pass.
3. pysqlflow: Release a new version of pysqlflow. Simply by make release.
4. sqlflow: Update sqlflow's service protocol and its Docker image to a new pysqlflow release sqlflow==0.2.0

I don't think introduce sqlflow in this repo is a good idea. pysqlflow shouldn't depend on sqlflow, since sqlflow are already depending on pysqlflow.

Not sure if only the docker image depends on pysqlflow, if so, it's not likely that it will cause dependency circle. It is an independented docker image used for providing quickstart demos that depends on both sqlflow and pysqlflow, not sqlflow depends on pysqlflow.

Maybe for best convenience, we can move pysqlflow into sqlflow repo as one directory, like most multi language repos, putting go code under pkg/ directory and python code under python/ directory. Then we release pysqlflow to pypi using CI using the same version number as sqlflow, then it will also be easy to find the correct version match.

@typhoonzero Please kindly allow me to explain.

Not sure if only the docker image depends on pysqlflow, if so, it's not likely that it will cause dependency circle. It is an independented docker image used for providing quickstart demos that depends on both sqlflow and pysqlflow, not sqlflow depends on pysqlflow.

sqlflow is responsible for the integration tests between sqlflow and pysqlflow. I consider it as one repo depending on another repo.

Maybe for best convenience, we can move pysqlflow into sqlflow repo as one directory, like most multi language repos, putting go code under pkg/ directory and python code under python/ directory. Then we release pysqlflow to pypi using CI using the same version number as sqlflow, then it will also be easy to find the correct version match.

I am certain combining these two repos makes updating the service protocol easier. However, shouldn't we make this procedure hard so that the service protocol won't be changed easily? Having two repos also enforces the version number change on every service update.

Also, a pure python repo is much easier to test and distribute.

I am certain combining these two repos makes updating the service protocol easier. However, shouldn't we make this procedure hard so that the service protocol won't be changed easily? Having two repos also enforces the version number change on every service update.

I'm sure there are cases like mysql-server and mysql-connector-python are separated repos, it's a common method used by projects around. And I also believe that when projects become larger, and many client implementations are needed it will be quiet needed to put things in seperated repo for better management.

Well since the current .proto file is tiny and only 1 RPC service is defined, it's cheap to copy it around. I accept both ways, and prefer to merge these two repos since they are both so "small".

I closed this inactive PR.