itsksaurabh / go-corona Goto Github PK

The logo of your library does not follow licences of below.

• The Go Gopher
• My illustration
• The logo of Go

Could you fix the logo to follow the licences.

Background

The github.com/itsksaurabh/go-corona uses Go modules and the current release version is v2. And it’s module path is "github.com/itsksaurabh/go-corona", instead of "github.com/itsksaurabh/go-corona/v2". It must comply with the specification of "Releasing Modules for v2 or higher" available in the Modules documentation. Quoting the specification:

A package that has opted in to modules must include the major version in the import path to import any v2+ modules
To preserve import compatibility, the go command requires that modules with major version v2 or later use a module path with that major version as the final element. For example, version v2.0.0 of example.com/m must instead use module path example.com/m/v2.
https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher

Steps to Reproduce

GO111MODULE=on, run go get targeting any version >= v2.0.0 of the itsksaurabh/go-corona:

$ go get github.com/itsksaurabh/[email protected]
go: finding github.com/itsksaurabh/go-corona v2.0.0
go: finding github.com/itsksaurabh/go-corona v2.0.0
go get github.com/itsksaurabh/[email protected]: github.com/itsksaurabh/[email protected]: invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v2

run go get github.com/itsksaurabh/go-corona, the version will stuck in v1.0.3:

$go get github.com/itsksaurabh/go-corona
go: downloading github.com/itsksaurabh/go-corona v1.0.3
go: github.com/itsksaurabh/go-corona upgrade => v1.0.3

SO anyone using Go modules will not be able to easily use any newer version of itsksaurabh/go-corona.

Solution

1. Kill the go.mod files, rolling back to GOPATH.

This would push them back to not being managed by Go modules (instead of incorrectly using Go modules).
Ensure compatibility for downstream module-aware projects and module-unaware projects projects

2. Fix module path to strictly follow SIV rules.

Patch the go.mod file to declare the module path as github.com/itsksaurabh/go-corona/v2 as per the specs. And adjust all internal imports.
The downstream projects might be negatively affected in their building if they are module-unaware (Go versions older than 1.9.7 and 1.10.3; Or use third-party dependency management tools, such as: Dep, glide,govendor…).

If you don't want to break the above repos. This method can provides better backwards-compatibility.
Release a v2 or higher module through the major subdirectory strategy: Create a new v2 subdirectory (github.com/itsksaurabh/go-corona/v2) and place a new go.mod file in that subdirectory. The module path must end with /v2. Copy or move the code into the v2 subdirectory. Update import statements within the module to also use /v2 (import "github.com/itsksaurabh/go-corona/v2/…"). Tag the release with v2.x.y.

3. Major version bump / repository change

Leave v2 as a dead version and bump to v3 with the path changes.

4. Suggest your downstream module users use hash instead of a version tag.

If the standard rule of go modules conflicts with your development mode. Or not intended to be used as a library and does not make any guarantees about the API. So you can’t comply with the specification of "Releasing Modules for v2 or higher" available in the Modules documentation.
Regardless, since it's against one of the design choices of Go, it'll be a bit of a hack. Instead of go get github.com/itsksaurabh/go-corona@version-tag, module users need to use this following way to get the itsksaurabh/go-corona:
(1) Search for the tag you want (in browser)
(2) Get the commit hash for the tag you want
(3) Run go get github.com/itsksaurabh/go-corona@commit-hash
(4) Edit the go.mod file to put a comment about which version you actually used
This will make it difficult for module users to get and upgrade itsksaurabh/go-corona.

[*] You can see who will be affected here: [3 module users, e.g., itsksaurabh/go-wazirx, dickysuryos/botWhatsappCovid, RTradeLtd/ipcoronafs]
https://github.com/search?q=itsksaurabh%2Fgo-corona+filename%3Ago.mod&type=Code

Summary

You can make a choice to fix DM issues by balancing your own development schedules/mode against the affects on the downstream projects.

For this issue, Solution 2 can maximize your benefits and with minimal impacts to your downstream projects the ecosystem.

References

• https://github.com/golang/go/wiki/Modules#semantic-import-versioning
• https://golang.org/cmd/go/#hdr-Module_compatibility_and_semantic_versioning
• https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher

GET ​/v2​/locations allows to add a province and county to filter data for a given country. Endpoints looking like the below:

• /v2/locations?source=jhu&country_code=<code>&province=<province>
• /v2/locations?source=jhu&country_code=<code>&province=<province>&county=<county>

Would it make sense to add another method to get data for a given province within a country and another one for a given county?

E.g (method signatures):

• func (c Client) GetDataByProvince(ctx context.Context, countryCode string, province string, timelines bool) (data Locations, err error)
• func (c Client) GetDataByCounty(ctx context.Context, countryCode string, province string, county string, timelines bool) (data Locations, err error)

However, I am not sure this is the best way to go about this (I think it's possible to filter by country and county and omit the province).
Another way I could think of would be to change the GetDataByCountryCode method signature to add 2 boolean arguments so that users could add province and/or county as filters, e.g:

func (c Client) GetDataByCountryCode(ctx context.Context, countryCode string, province bool, county bool, timelines bool) (data Locations, err error)

And then create the endpoint accordingly if those are set to true.
Either way, it might not be useful to add this, so feedback welcome.

The name goes very well. corona.go