potiuk commented on PR #53149: URL: https://github.com/apache/airflow/pull/53149#issuecomment-3064800965
I made the first pass and comments. It looks cool, but I really think it will shine when we split the shared parts into shared functionalities that can be treated as separate "standalone" sub-projects, opened independenty, tested independently and with uv workspace and `uv sync` powers to isolate local venv to **only** what the sub-project needs - we can have truly independent, internally reusable pieces of functionality (rather than throwing everything into a "bag of shared code"). Some suggestions and concrete proposals how to make it in this direction added. Also I have not seen the `hatch-build-vendoring` project code - which is pretty crucial to the whole thing. And I think we need to discuss and agree what we do with this code. I understand that the idea is to release it separately as a PyPI project - who is going to be the owner and do the governance? What licence it is going to have and are we sure it's going to be maintained? Is it going to be "Apache" owned or 3rd-party owned? My first thought with it is that it will be difficult to make it a "reusable" project from get go and if we find any issues or for example will have to adapt to a new hatchling version (btw - the project is really a `hatchling` not `hatch` plugin I believe so maybe name should be different). Likely - better approach at least for a while will be to include the project inside airflow (similarly to breeze) and make it robust and fix things (following "if you want to make somethign reusable, make it usable first") - but that has implication on the ownership of the code of course - because it will have to be donated to the ASF (but it is not a big issue because it could be forked without any implications and released separately later if needs be anyway. I just feel that having it released as separate project will make it way more difficult to fix things when we find problems affecting many contributors and need to fix them quickly - at least in the initial phase. This is the same "class" of problems that we have with sphinx-airflow-theme - still not solved - because in order to fix things you need to do a series of things including making the new version released in PyPI - which I think would be quite problematic. For example if only @ashb would be owning it or even @ashb and @kaxil -> then we would need the owners to be available to merge and release any fixes - and until this happens we would be pretty blocked. So I would very much prefer to have this project in airflow repo and simply installing it from the local path. -- 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]
