Go modules migration
Denys Smirnov
Hi everyone,
Go 1.12 was recently released and since our version support policy includes two latest Go releases, I think it’s the right time to plan the migration to Go modules.
Currently, we have 4 project groups for the migration, each with different requirements:
Applications: enry, bblfshd, bblfsh-web
Clients: libuast, Go client
Babelfish SDK
Babelfish drivers
Applications, clients, and drivers depend on the SDK. Enry is the only exception and has no dependency on SDK.
Most of the projects can be updated separately. Since “go mod init” supports Dep manifests, it is possible to first migrate application and clients first and then update the SDK. First tests show that there should be no issues with the migration.
It’s worth to note, that we currently use gopkg.in to support multiple major versions of SDK under different import paths, which is similar to semantic import versioning concept introduced with Go modules. Since modules already provide a better mechanism for supporting multiple major versions, I think it’s reasonable to synchronize the switch to modules and deprecation of gopkg.in import paths.
Still, we don’t want to break existing drivers that will continue to use gopkg.in imports. To ensure smooth migration we should fork and archive the current SDK version under a different repository name and redirect gopkg.in to this fork. After this, the main repository can switch import paths to Github instead of gopkg.in proxy and use Go modules manifest instead of Dep.
After the SDK is migrated, we can start updating drivers. Drivers are a special case and will require more time to migrate. Most Go files in the driver are managed by the SDK, and despite SDK itself will be migrated, driver skeleton will need to be updated separately.
We don’t have any specific deadline for the migration at the moment, and the progress will be tracked separately in each project.
Please let us know if you have any ideas or concerns regarding the migration.
Denys,
On behalf of core Babelfish maintainers.
Alex Bzz
On Tuesday, March 26, 2019 at 2:42:01 PM UTC+1, Denys Smirnov wrote:
Hi everyone,
Go 1.12 was recently released and since our version support policy includes two latest Go releases, I think it’s the right time to plan the migration to Go modules.
Currently, we have 4 project groups for the migration, each with different requirements:
Applications: enry, bblfshd, bblfsh-web
Clients: libuast, Go client
Babelfish SDK
Babelfish drivers
Applications, clients, and drivers depend on the SDK. Enry is the only exception and has no dependency on SDK.
Most of the projects can be updated separately. Since “go mod init” supports Dep manifests, it is possible to first migrate application and clients first and then update the SDK. First tests show that there should be no issues with the migration.
It’s worth to note, that we currently use gopkg.in to support multiple major versions of SDK under different import paths, which is similar to semantic import versioning concept introduced with Go modules. Since modules already provide a better mechanism for supporting multiple major versions, I think it’s reasonable to synchronize the switch to modules and deprecation of gopkg.in import paths.