Skip to content

Commit

Permalink
leverage Sphinx file role in docs
Browse files Browse the repository at this point in the history
  • Loading branch information
jakob-keller committed Aug 24, 2024
1 parent fe3f50c commit ececd32
Showing 1 changed file with 7 additions and 7 deletions.
14 changes: 7 additions & 7 deletions CONTRIBUTING.rst
Original file line number Diff line number Diff line change
Expand Up @@ -68,31 +68,31 @@ botocore calls eventually called.

The best way I've seen to upgrade botocore support is by performing the following:

1. Download sources of the release of botocore you're trying to upgrade to, and the version of botocore that aiobotocore is currently locked to (see pyproject.toml) and do a folder based file comparison of the botocore folders (tools like DiffMerge are nice).
1. Download sources of the release of botocore you're trying to upgrade to, and the version of botocore that aiobotocore is currently locked to (see :file:`pyproject.toml`) and do a folder based file comparison of the botocore folders (tools like DiffMerge are nice).
2. Manually apply the relevant changes to their aiobotocore equivalent(s). Note that sometimes new functions are added which will need to be overridden (like *__enter__* -> *__aenter__*)
3. Update the "project.optional-dependencies" in pyproject.toml to the versions which match the botocore version you are targeting.
3. Update the "project.optional-dependencies" in :file:`pyproject.toml` to the versions which match the botocore version you are targeting.
4. Now do a directory diff between aiobotocore and your target version botocore directory to ensure the changes were propagated.

See next section describing types of changes we must validate and support.

Hashes of Botocore Code (important)
-----------------------------------
Because of the way aiobotocore is implemented (see Background section), it is very tightly coupled with botocore. The validity of these couplings are enforced in test_patches.py. We also depend on some private properties in aiohttp, and because of this have entries in test_patches.py for this too.
Because of the way aiobotocore is implemented (see Background section), it is very tightly coupled with botocore. The validity of these couplings are enforced in :file:`test_patches.py`. We also depend on some private properties in aiohttp, and because of this have entries in :file:`test_patches.py` for this too.

These patches are important to catch cases where botocore functionality was added/removed and needs to be reflected in our overridden methods. Changes include:

* parameters to methods added/removed
* classes/methods being moved to new files
* bodies of overridden methods updated

To ensure we catch and reflect this changes in aiobotocore, the test_patches.py file has the hashes of the parts of botocore we need to manually validate changes in.
To ensure we catch and reflect this changes in aiobotocore, the :file:`test_patches.py` file has the hashes of the parts of botocore we need to manually validate changes in.

test_patches.py file needs to be updated in two scenarios:
:file:`test_patches.py` file needs to be updated in two scenarios:

1. You're bumping the supported botocore/aiohttp version. In this case a failure in test_patches.py means you need to validate the section of code in aiohttp/botocore that no longer matches the hash in test_patches.py to see if any changes need to be reflected in aiobotocore which overloads, on depends on the code which triggered the hash mismatch. This could there are new parameters we weren't expecting, parameters that are no longer passed to said overriden function(s), or an overridden function which calls a modified botocore method. If this is a whole class collision the checks will be more extensive.
1. You're bumping the supported botocore/aiohttp version. In this case a failure in :file:`test_patches.py` means you need to validate the section of code in aiohttp/botocore that no longer matches the hash in test_patches.py to see if any changes need to be reflected in aiobotocore which overloads, on depends on the code which triggered the hash mismatch. This could there are new parameters we weren't expecting, parameters that are no longer passed to said overriden function(s), or an overridden function which calls a modified botocore method. If this is a whole class collision the checks will be more extensive.
2. You're implementing missing aiobotocore functionality, in which case you need to add entries for all the methods in botocore/aiohttp which you are overriding or depending on private functionality. For special cases, like when private attributes are used, you may have to hash the whole class so you can catch any case where the private property is used/updated to ensure it matches our expectations.

After you've validated the changes, you can update the hash in test_patches.py.
After you've validated the changes, you can update the hash in :file:`test_patches.py`.

One would think we could just write enough unittests to catch all cases, however, this is impossible for two reasons:

Expand Down

0 comments on commit ececd32

Please sign in to comment.