Use dynamic versioning #15
Conversation
the version was added in some comments/logs info; this does not play
well when we re-generate the code from a branch with dynamic
versioning
| @@ -1,15 +1,12 @@ | |||
| #!/bin/bash | |||
|
|
|||
| version=$(cat VERSION) | |||
There was a problem hiding this comment.
I wanted to do version=$(uvx --from setuptools-scm python -m setuptools_scm) but the version is hardcoded in the source when we generate the code (nothing major, only logs). One option was to change the mustache template, but I think it's too much hassle for this.
There was a problem hiding this comment.
question: Could you elaborate on this one? Is this basically a "chicken egg problem"? setuptools_scm needs a tag, a tag needs a comment, a commit needs the code, the code needs the version from setuptools_scm?
If so, what's the takeaway? This could be a strong counter-argument not to use setuptools_scm in the first place, or could be neglected because it's not important?
If this is not going to be set, then it would at least make sense to use a partial workaround (by using the httpUserAgent setting).
But it would be very interesting to see which versions of the SDK are actually being used to communicate with the LocalStack runtime, so a proper versioning in the http user agent could be quite beneficial...
There was a problem hiding this comment.
Really nice to see that uv overcame the issues we have.
I am still a bit confused with the drop of the version argument in the generation script, as I think this would drastically limit the access to data indicating the usage of the different SDK versions...
Maybe we can fix this, or at least make the impact of this change explicit / make a conscious decision?
| @@ -1,15 +1,12 @@ | |||
| #!/bin/bash | |||
|
|
|||
| version=$(cat VERSION) | |||
There was a problem hiding this comment.
question: Could you elaborate on this one? Is this basically a "chicken egg problem"? setuptools_scm needs a tag, a tag needs a comment, a commit needs the code, the code needs the version from setuptools_scm?
If so, what's the takeaway? This could be a strong counter-argument not to use setuptools_scm in the first place, or could be neglected because it's not important?
If this is not going to be set, then it would at least make sense to use a partial workaround (by using the httpUserAgent setting).
But it would be very interesting to see which versions of the SDK are actually being used to communicate with the LocalStack runtime, so a proper versioning in the http user agent could be quite beneficial...
|
@alexrashed yes, this was kind of a chicken-egg problem. I agree with you, it would be nice to know which SDK version is communicating with LocalStack.
|
| build-backend = "setuptools.build_meta" | ||
|
|
||
| [tool.setuptools_scm] | ||
| version_file = "localstack-sdk-python/localstack/sdk/version.py" |
There was a problem hiding this comment.
praise: Nice! Using the native feature of setuptools_scm for version-single-sourcing is a great idea! 💯
| @@ -30,3 +31,5 @@ def __init__(self, host: str | None = None, auth_token: str | None = None, **kwa | |||
| self.auth_token = auth_token | |||
| self.configuration = Configuration(host=self.host) | |||
| self._api_client = ApiClient(configuration=self.configuration) | |||
| # The generated code comes with 1.0.0 hard-coded. We set here the correct version | |||
| self._api_client.user_agent = f"LocalStack SDK/{version.version}/python" | |||
There was a problem hiding this comment.
nitpick (non-blocking): Maybe something for the next iteration, but this is a bit risky / could break if teh internals of the generated API client breaks. It might make sense to explicitly test this in the future?
uvnow omits dynamics versions from the lock file (see astral-sh/uv#10622).This allows us to switch to
setuptools_scmto manage versioning with the usage of tags (similarly to what we do in LocalStack core).This PR introduces the needed changes to the
pyproject.tomlfiles.