lookout icon indicating copy to clipboard operation
lookout copied to clipboard

lookout-sdk binary should expose SDK library version

Open bzz opened this issue 7 years ago • 7 comments

The idea is that any client using lookout-sdk binary should be able to make sure that he uses the right binary, supporting his exact SDK library version.

As client already knows an SDK version he uses, it should be enough to just expose the SDK version that lookout-sdk binary was build across i.e though CLI of lookout-sdk version.

That way the client could check if it matches his desired version and fail fast, avoiding possible tricky gRPC compatibility errors at later runtime stages.

E.g. this would allow for caching lookout-sdk binary on CI and only downloading it from Github in case version does not match.

Motivated by discussion in https://github.com/src-d/style-analyzer/issues/95#issuecomment-418726078

bzz avatar Sep 06 '18 14:09 bzz

I looked into this and it was not obvious how to proceed. From the src-d/lookout repository the only place to check the exact version of the src-d/lookout-sdk build we import is Gopkg.lock. As the lookout-sdk binary may be moved to the src-d/lookout-sdk repo maybe it's better to wait.

carlosms avatar Sep 10 '18 17:09 carlosms

What do you think would be a better place to take this information from, after moving binary to src-d/lookout-sdk?

bzz avatar Sep 18 '18 13:09 bzz

If we move the binary to the src-d/lookout-sdk repo, we can use the version & build set by the makefile from src-d/ci, right?

carlosms avatar Sep 19 '18 13:09 carlosms

Another solution to this issue would be to export sdk version in go sdk, same as we do in python sdk: https://github.com/src-d/lookout-sdk/blob/master/python/lookout/sdk/init.py

Then lookout-tool can just print it.

@carlosms wdyt?

smacker avatar Jan 09 '19 12:01 smacker

I don't like the idea of having another variable that we need to update manually before each release, but at this point that seems to be the most reasonable solution, yes.

carlosms avatar Jan 09 '19 12:01 carlosms

I suggest having only 1 variable somewhere in the sdk. And update python&go sdk to read it.

smacker avatar Jan 09 '19 12:01 smacker

I have tried a few solutions for having it only in one place and I don't like the result at all.

Let's pause this issue for now as we are returning to a discussion about moving the binary to another repo.

If at the and we still will want to have the version in source code and more than in 1 place, I would suggest to create make bump to take care of update.

smacker avatar Jan 11 '19 14:01 smacker