Feature/workspace py requires#19851
Conversation
* wip * more rid * wip
* doc retry conf and change default * fix tests
…an-io#19829) * Improve items() * Improve items documentation * Fix docstring
| self.conan_data = self._conan_load_data() | ||
| self._conan_api = conan_api | ||
| self.output = ConanOutput(scope=f"Workspace '{self.name()}'") | ||
| self._loader = None |
There was a problem hiding this comment.
the only change to workspace.py is instead of declaring and creating its own (and incomplete) loader, it gets the object from the caller
| packages[reference] = pkg | ||
| # This needs to be incremental, in the loop, so loaded ones are made available | ||
| # for next iterations that might require python-requires in their ws.load_conanfile | ||
| editable_packages.edited_refs[reference] = pkg |
There was a problem hiding this comment.
This is the core change/proposal. Incremental adding to the editable_packages object, that is shared by ConanProxy, RangeResolver, the packages that are loaded from the workspace.
| # This is caching too! | ||
| loader = ConanFileLoader(pyreq_loader, conanfile_helpers) | ||
| return proxy, range_resolver, loader, None | ||
| ws_packages = self._conan_api.workspace._load_packages(loader, editable_packages) # noqa |
There was a problem hiding this comment.
This implements the chicken and egg, instead of doing it in one shot in self._conan_api.workspace.packages(), it executes over the editable_packages object, so it adds incrementally to it, so the ConanProxy and RangeResolver immediately get knowledge of the added editables in the workspace, so they can resolve to them if necessary, like former python-requires.
Changelog: Feature: Allow
python_requiresinworkspaceDocs: https://github.com/conan-io/docs/pull/XXXX
Close #19793
This builds on top of #19797, and still super-dirty.
It is not guaranteed to be moved forward, I am thinking that maybe workspaces should be focused on C/C++ work, not simultaneously modifying some python-requires, which are tools for recipes, bug workspaces are focused on the C/C++ development experience.
A python-require to work on it could be added as globally editable relatively easy. So not sure if the complexity added by this PR would be worth (the way it works to solve chicken-and-egg problem is very subtle, by sharing a common object that gradually gets the workspace package definitions incrementally while resolving them, so that means that python requires should always come first, but this is fragile.