potiuk commented on code in PR #47017:
URL: https://github.com/apache/airflow/pull/47017#discussion_r1967510388
##########
contributing-docs/quick-start-ide/contributors_quick_start_pycharm.rst:
##########
@@ -39,12 +39,30 @@ Setup your project
alt="Cloning github fork to Pycharm">
</div>
-3. Configure the source root directories for providers as well as for task_sdk.
+3. Configure the source root directories well as for task_sdk. You also have to
+ set "source" and "tests" root directories for each provider you want to
develop (!).
+ This is important in Airflow 3.0 we split providers to be separate
+ distributions - each with separate ``pyproject.toml`` file, so you need to
separately
Review Comment:
And yes - that's a price to pay for isolation. We alrady have workspace in
`uv` that allows us to `eat cake` and `have it too` for venv setup and running
tests from commandline. - where we have providers isolated, but also we can
develop things separately. Hopefully when IntelliJ will bring their `uv
workspace` setup to be better, this will not be needed and will happen
"automagically" - but we are not there yet, also I don't think having IDE setup
for all providers is needed in nearly any workflow I can imagine for an average
contributor.
BTW. There is also one more possibility (and that one will be even more
exciting) - which **almost** works now - as a contributor you will be able to
just open the folder of provider as the "Pycharm" or "IntelliJ" project. -
without opening "airflow" project - and ONLY work on provider. There are a few
more things needed for this to happen:
* tests_common needs to be separated out as a separate distribution and made
into dependency of individual providers
* doc building now entirely relies on being run in "airflow" - you can
specify which provider doc you want to build, but it needs to be run in
"airflow" project
Once we have it, vast majority of people who need to contribute to a
provider, will be able to just point their pycharm to the provider folder, open
project there, run tests, build docs and get it all without ever touching
"airlfow" main project (except pre-commits will always run in the main airflow
repo, but that has very little to do with developing provider code).
So I think the way it is set-up now is certainly "good enough" and will be
"better" once we get all those remaining pieces done.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
