Relationship between this project and Container Analysis API in GCP.

[Brian Costlow]

I recently opened an issue for the open source Python grafeas client.

https://github.com/grafeas/client-python/issues/9

And was planning on working on it myself. But before I throw myself into this...

Is this project upstream of the GCP platform?  Is there any effort made to keep things compatible at the API layer between the two or have they forked?

There appears to be an open-sourced, well-maintained Python client for the GCP offering at https://github.com/googleapis/python-grafeas, created from the protocol buffers by Google tooling instead of the swagger/OpenAPI files.

If the goal is to keep both this and the GCP offering in sync, is working on a separate client Python SDK worth doing, since Google's should work with both? 

I also notice that the googleapi one is in PyPI, and what you get if you naively pip install from there.

Assuming that there is a reason to maintain this separate client, a few further questions come to mind:

1. Is there a desire to package this client (under a different name) in PyPI as well? Note that a recent change to make the Python client package version synonymous with the api version is not compatible with https://www.python.org/dev/peps/pep-0440/

2. Should I keep the alpha version of the api in the package, such that it's not the default, but still reachable, or should I just eliminate it?

3. Swagger generates test stubs, but they've not been filled in. Is this because nobody has had time to work on it, or do the project owners feel that it's not needed?

4. If tests are wanted, preference for (obvs highly mocked) unit tests, or e2e tests with the Dockerized Grafeas server first?

5. Is there a general road map doc for the server and clients? Is this generally a do-ocracy or should I seek guidance somewhere before haring off and doing what I think is right?

[Wiktor Kozlik]

Hi Brian,

Thank you for taking time for putting together this list of questions. The main difference between these two projects is exactly what you observed, that one is created from the protocol buffers by Google tooling, and the other from the swagger/OpenAPI files. Both of these projects are meant to provide a client library for the Grafeas API https://github.com/grafeas/grafeas. The goal is to keep all Grafeas clients up to date, but that varies depending on the interest from the community. The Grafeas project https://github.com/grafeas/grafeas is up to date, and it is actively maintained since it used by the GCP platform. 

1. Is there a desire to package this client (under a different name) in PyPI as well? Note that a recent change to make the Python client package version synonymous with the api version is not compatible with https://www.python.org/dev/peps/pep-0440/

It is a good question. Could you make a recommendation?

2. Should I keep the alpha version of the api in the package, such that it's not the default, but still reachable, or should I just eliminate it?

Since v1 has been available for a while, I don't think there is a reason for keeping the alpha version. 

3. Swagger generates test stubs, but they've not been filled in. Is this because nobody has had time to work on it, or do the project owners feel that it's not needed?

I think it is a combination of things. Lack of time is definitely the factor, but there are also issues with Google HTTP annotations not being compatible with Swagger. https://github.com/grafeas/grafeas/issues/379#issuecomment-531797226

4. If tests are wanted, preference for (obvs highly mocked) unit tests, or e2e tests with the Dockerized Grafeas server first?

Mocked unit tests would be my preference, mainly to avoid dependency on Docker if possible. But feel free to use your judgement. 

5. Is there a general road map doc for the server and clients? Is this generally a do-ocracy or should I seek guidance somewhere before haring off and doing what I think is right?

I think the goal is to have the open source community help to set the direction, so your contribution will be greatly appreciated!

Thanks,

Wiktor

[Brian Costlow]

Hi Wiktor,

Thanks for the response. My end goal is to try and get the open source sever up and running, and working with Java and Python clients. This is where I get confused, when you say: 

the Grafeas project https://github.com/grafeas/grafeas is up to date, and it is actively maintained since it used by the GCP platform. 

The public Grafeas docker image I grabbed seemed to be exposing the v1beta1 version of the API,  while the GCP version is exposing v1.  I am a Golang newb, can you build and run the v1 endpoints, and use the googleapi clients against the open source grafeas? 

If I need to dig in and work on the clients in the grafeas repo, so be it, but I'd love it if there was a "path of least resistance" which let me use the much more actively developed googleapi clients with the open source server.

[Aysylu Greenberg]

Hi Brian,

Thank you for your interest in contributing to Grafeas! The current reference server implementation only implements the v1beta1 API, so it'd need updating to use v1 API instead. The reason for this is that v1 API was WIP at the time the server reached 0.1.0 and was publicly announced. The googleapi clients have additional functionality around the auth layer that you may or may not need; the Grafeas client portion of it is the same though, so you should be able to use it.

To add to what Wiktor mentioned in response to the earlier question, in the longer term, Grafeas API, its reference server implementation, storage backends, and API clients are treated as completely independent  in the GH repo, per its architecture diagram. Contributions to continue these improvements are welcome!

Cheers,

Aysylu

--
You received this message because you are subscribed to the Google Groups "Grafeas Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grafeas-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grafeas-dev/16c5cb75-3d1f-4a9a-a1d3-9ac2404c20ecn%40googlegroups.com.