-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: add async_rest
extra for async rest dependencies
#2195
chore: add async_rest
extra for async rest dependencies
#2195
Conversation
25c7c19
to
a6c1789
Compare
google-auth | ||
# from google-auth[aiohttp] | ||
aiohttp | ||
requests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We shouldn't include the async_rest
extra in all constraints because we won't have any tests without the async_rest
extra installed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
addressed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure this is true. The nox
documentation says "[session.install] invokes pip to install packages inside of the session’s virtualenv." We use session.install
like this, specifying -c CONSTRAINTS_FILE
. The -c
constraints files option for pip
is documented as saying (emphasis added) "Constraints files are requirements files that only control which version of a requirement is installed, not whether it is installed or not" .
So in other words, removing async_rest
from the constraints will not do what we want. It doesn't matter whether we have it there or not, as long as we make sure that we do not install the extras. So I would argue it's better to not split the constraints files, but to have one test suite that installs the async_rest
extra and one test suite that doesn't, both with the same constraints file.
Does this make sense? LMK if I've misunderstood something.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
addressed. See my other comment and discussing this over our offline chat.
aiohttp==3.6.2 | ||
requests==2.20.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider creating a separate constraints file so that we know that the client library without the async_rest
extra works. See googleapis/python-api-core#701 where we have a separate constraints file testing/constraints-async-rest-3.7.txt
and separate nox session for testing async_rest
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
addressed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See comment above.
{# NOTE: `pragma: NO COVER` is needed since the coverage for presubmits isn't combined. #} | ||
except ImportError as e: # pragma: NO COVER | ||
{# TODO(https://github.com/googleapis/google-auth-library-python/pull/1577): Update the version of google-auth once the linked PR is merged. #} | ||
raise ImportError("async rest transport requires google-auth >= 2.35.0 with aiohttp extra. Install google-auth with the aiohttp extra using `pip install google-auth[aiohttp]==2.35.0`.") from e | ||
raise ImportError("`rest_asyncio` transport requires the library to be installed with the `async_rest` extra. Install the library with the `async_rest` extra using `pip install <insert_library_name>[async_rest]`") from e |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we use {{ api.naming.warehouse_package_name }}
instead of <insert_library_name>
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
addressed.
tests/integration/goldens/redis/tests/unit/gapic/redis_v1/test_cloud_redis.py
Show resolved
Hide resolved
...egration/goldens/redis/google/cloud/redis_v1/services/cloud_redis/transports/rest_asyncio.py
Outdated
Show resolved
Hide resolved
async_rest
extra for async rest dependencies
google-auth | ||
# from google-auth[aiohttp] | ||
aiohttp | ||
requests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure this is true. The nox
documentation says "[session.install] invokes pip to install packages inside of the session’s virtualenv." We use session.install
like this, specifying -c CONSTRAINTS_FILE
. The -c
constraints files option for pip
is documented as saying (emphasis added) "Constraints files are requirements files that only control which version of a requirement is installed, not whether it is installed or not" .
So in other words, removing async_rest
from the constraints will not do what we want. It doesn't matter whether we have it there or not, as long as we make sure that we do not install the extras. So I would argue it's better to not split the constraints files, but to have one test suite that installs the async_rest
extra and one test suite that doesn't, both with the same constraints file.
Does this make sense? LMK if I've misunderstood something.
aiohttp==3.6.2 | ||
requests==2.20.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See comment above.
noxfile.py
Outdated
constraints_path = str( | ||
f"{tmp_dir}/testing/constraints-{session.python}.txt" | ||
f"{tmp_dir}/testing/constraints-{constraints_type}{session.python}.txt" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A note: unlike what I remarked on another comment thread in this PR, where we're using the constraints files as -c
arguments to PIP (which hence do not control whether those dependencies are installed), here we are passing the file via -r
(three lines below) thus making it into a requirements file where the listed dependencies are installed. AFAICT, we do not use -r
for the (same??!) constraints files under templates/
.
We should be clear about the semantics and how we are using the files. I'd suggest for the purposes of this file, creating proper requirements files that do list what will be installed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed the constraints file.
We're infact installing the constraints
file with a -r
flag which is why this wasn't an issue here (at least at the generator layer). Anyways, this has been addressed by installing the deps with the extra.
@@ -94,6 +98,9 @@ setuptools.setup( | |||
packages=packages, | |||
python_requires=">=3.7", | |||
install_requires=dependencies, | |||
{% if rest_async_io_enabled %} | |||
extras_require=extras, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So if this wasn't there before, why weren't some tests failing? This would suggest a failure in our tests. At the GAPIC level, the test should silently pass if the GAPIC was generated without REST transport or installed without the extra. But at the generator level, we want to ensure that the tests with the extras pass, so how can we be notified if we run a test suite where we expect the extra and the associated tests, but it turns out the extra wasn't installed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tests weren't failing because we're not using the async_rest
extra to install the dependencies. We've explicitly defined each required dependency within the constraints file.
Fixes #2187 🦕