There’s an open source python library, let’s call it foo, and several other open source projects that depend on it, foo-configurator, foo-manager, etc.
I want to make a fork of foo to change the way it works under the hood (in a way that it needs to be a fork, it’s a library that interfaces with industrial hardware and we’re making one that interacts with our stuff that’s pretty different than what’s existing). So my fork would be called something like other-foo. The problem is I still want the other open source projects which use foo to be able to work with my other-foo as well, but they will fail on installation since their dependency check is looking foo and not other-foo.
Is there a way for me to handle this as the creator of other-foo, to spoof or somehow present as foo in terms of dependencies, but still have a package name of other-foo?
These foo libraries deal with industrial hardware devices, so there’s no chance that foo and other-foo will be installed at the same time.
The only way I can think to solve this would be to change the setup configurations of the other utility projects, (foo-configurator, etc.) to use dependency options and extras_require settings, so someone could install them in an environment with other-foo by using pip install foo-configurator[other-foo] or whatever. But that would require me to get these other projects on board, and also I think the extras_require can only add package dependencies to what’s already there, so them adding and extras_require for other-foo won’t remove the need for foo, so maybe that’s not the correct route?
The only other way I can think to do this is to fork all those other projects too, and change just the setup config to require other-foo instead of foo, but then I would need to maintain forks and that seems like a huge pain.
So, any ideas for the best, most pythonic way to handle this situation? Thanks!