It adds a User-Agent header to requests with the format carto-python-sdk/x.y.z where x.y.z is the version number. E.g: User-Agent: carto-python-sdk/1.3.0. This replaces the default one, from requests library, which has the form python-requests/x.y.z.
It adds a parameter client with the format cps-X.Y.Z. E.g: client=cps-1.2.0. It is modeled after CARTO.js client parameter.
Why we want this:
The User-Agent header let us clearly identify all issued requests at nginx level. This is in general useful for debugging.
The client parameter let us do things at the application level, such as issuing warnings for certain versions, plus it also allows for better debugging (think of a client bug in a given version).
As requested by @rochoa and hoping this helps in knowing better how our platform is used beyond COPY.
This is done on top of the COPY branch, just because it's a clean slate with respect to CI tests.
What this does:
It adds a
User-Agentheader to requests with the formatcarto-python-sdk/x.y.zwherex.y.zis the version number. E.g:User-Agent: carto-python-sdk/1.3.0. This replaces the default one, fromrequestslibrary, which has the formpython-requests/x.y.z.It adds a parameter
clientwith the formatcps-X.Y.Z. E.g:client=cps-1.2.0. It is modeled after CARTO.jsclientparameter.Why we want this:
User-Agentheader let us clearly identify all issued requests at nginx level. This is in general useful for debugging.clientparameter let us do things at the application level, such as issuing warnings for certain versions, plus it also allows for better debugging (think of a client bug in a given version).As requested by @rochoa and hoping this helps in knowing better how our platform is used beyond COPY.
This is done on top of the COPY branch, just because it's a clean slate with respect to CI tests.