I am working on a project A that depends on a wheel B that I also develop.
When I have to make changes to B's interface, I need to reflect the change into the main project A, rebuild the wheel, install it and debug both. It's important to me to keep B as a wheel instead of a local subproject because the imports may behave differently, and when I debug I want the specific behaviour I get if I ran the tool with the wheel installed without access to any local files.
I have created a workflow to make this a bit less tedious, but it is fairly error-prone:
I keep both projects in two separate PyCharm instances. My main project A contains the installed wheel of my last working version of B. Whenever I need to refactor or change something in B, I do it right in the A project, which means I adapt the files of B in site-packages directly (dangerous, I know). When I am happy with the changes, I use Beyond Compare to move everything over from site-packages to the actual B project codebase, rebuild the wheel and reinstall it into A.
I don't particularly like this workflow and would prefer something like Visual Studio does in C++ where I can have multiple projects in one large solution and all the dependencies resolve on their own whenever I run the main project.
In PyCharm's case that would mean that I could work on project B right from the same instance that also holds the main project A, but PyCharm understands that B is not a local subproject of B, but instead needs to be treated as a wheel before actually having access to the changes I made. Any changes in B would automatically trigger a wheel rebuild and install when I run A. And while coding, the dependencies between A and B should also be understood so that if I need to e.g. change a function signature in B, it will refactor into A as well.
Is something like this available? Is it planned? Am I asking too much or make this issue overly complicated?