Refactor extras so that the logic is in one place - #2382
Conversation
…ates through the callers
|
Very cool! Please make sure to move over the regression tests from #2381 so it’s clear that these cases are fixed. We need to make sure that further changes don’t regress. Comments that don’t need to be part of this PR: I do wonder why this PR has a positive diff ratio. If it would unify the logic, wouldn’t that mean that there’s more code reuse and the diff is neutral or negative? Or is that because of the hatch-hatchling split so the logic is duplicated between both? If so – why is removing hatchling as a runtime dependency a goal if it contains logic we otherwise need to duplicate in |
The code reuse is there but in order to properly centralize the logic it required an additional function in Project. In terms of removing hatchling as a runtime dependency as a goal, hatch as a CLI should not require hatchling the build backend in order to be used. The same is true of hatchling which already does not require hatch to be used. We are trying to have that decoupling be completed fully. Right now hatchling has to be installed even if it is not the build backend that will be used. |
AI bot review is not considered valid approval for this
|
Very cool, thank you! I feel like with all the different properties, the design could still be simplified, but that’s not as urgent as a fix. |
* Refactor extras so that the logic is in one place and properly propogates through the callers * Fix type issue * Formatting * Further refactor and add tests to cover the cases known to have regressions previously * Reformat after refactor * additional bug fixes. * undefined-feature check should run unconditionally * Add doc strings, return tuples and reduce the resolve_extras calls * Add doc strings, return tuples and reduce the resolve_extras calls * Fix type check import ed8e30b
3 participants
Refactoring extras to properly be handled in one place this will prevent the regressions that have been happening hopefully.