Restrict looker-sdk version 24.18.0 and microsoft-kiota-http 1.3.4

[gopidesupavan]

The latest looker-sdk version causing import problems in our CI. so restricting 24.18.0 looker-sdk version.

https://github.com/apache/airflow/actions/runs/11295803154/job/31419668010?pr=42950#step:14:1642

There issue already opened here: looker-open-source/sdk-codegen#1518

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in newsfragments.

[gopidesupavan]

microsoft provider tests are failing due to import errors, its because of the latest microsoft-kiota-http release. and in microsoft provider using msgraph_core (this internally uses kiota-http) causing issues.

[gopidesupavan]

Is there any place we can restrict the pip versions which are indirectly installed, in this case kiota-http is using inside msgraph_core, how to restrict pip version?

[gopidesupavan]

not sure whether update microsoft-kiota-http pip version works or not , but i am trying out.

[potiuk]

Is there any place we can restrict the pip versions which are indirectly installed, in this case kiota-http is using inside msgraph_core, how to restrict pip version?

It's a bit case-by-case.

Usually it is ok to add such transitive dependency directly to provider as additional dependency - we've done that a number of times in the past - also it is often accompanied by an issue to the upstream project to let them know they have incompatibility and suggest to add similar transitive dependency in their package. What you've done here is following that and is a valid approach.

However, often it turns out, that such "transitive dependency" limit is already added in a newer version of our direct dependency - but only in one of the latest versions and uv or pip do not resolve the latest version automatically - in such case we can also bump minimum version of such direct dependency. But this is really something that rquires to take a close look at history of changes in dependencies of such dependencies and understanding them.

[potiuk]

Thanks for the fix @gopidesupavan BTW :)

[gopidesupavan]

Thanks @potiuk 😄 , updated the issue ids to provider yaml.

[gopidesupavan]

mypy-provider check for appflow not satisfying, not sure might be cache issue..

[gopidesupavan]

Can this be merged please? One test is failing, it looks like flaky test, will have a look and check-in separate pr