S3 Image Test Results (AMD64 / ARM64)

  2 files  ±0    2 suites  ±0   3m 0s ⏱️ +3s
394 tests ±0  343 ✅ ±0   51 💤 ±0  0 ❌ ±0 
788 runs  ±0  686 ✅ ±0  102 💤 ±0  0 ❌ ±0 

Results for commit ea1a7b3. ± Comparison against base commit 0f4b52e.

♻️ This comment has been updated with latest results.

LocalStack Community integration with Pro

    2 files  ±0      2 suites  ±0   1h 30m 33s ⏱️ +33s
2 707 tests ±0  2 452 ✅ ±0  255 💤 ±0  0 ❌ ±0 
2 709 runs  ±0  2 452 ✅ ±0  257 💤 ±0  0 ❌ ±0 

Results for commit f39c3bb. ± Comparison against base commit 0f4b52e.

♻️ This comment has been updated with latest results.

thanks for taking a stab at this @silv-io! could you clarify for posterity why we need a VERSION file in this iteration? wouldn't introducing the version module and localstack.version.__version__ be enough?

@thrau, there are multiple benefits to that.

As you can see in the changes, many of the scripts just get way easier to handle when having the version source separated into a simple text file. This is also mentioned as a benefit in the PyPA guide in (4.):

An advantage with this technique is that it’s not specific to Python. Any tool can read the version.

So no need to use grep, awk and sed anymore here. While extracting the version with these tools is fairly easy, any change we might make at some point might be error-prone because of the heavy usage of regex patterns. A simple cat VERSION won't lead to many errors when trying to change things :)

Another point is that in a multi distribution setup it is also much easier to send a plain version file to subpackages that they can reference in the pyproject.toml, than to write a script which would put a python version file in exactly the right spot for all the different distributions.