There are several ways to avoid this restriction, including:
- Release your fork to PyPI under a different name. This is by far the most popular solution AFAIK. You don’t need to change the import name if you don’t want to either, although I highly recommend you to do so, to avoid installation conflicts if the upstream package is required by another dependency.
- Vendor the fork (i.e. include the forked package in your package, and import that instead). This is more or less the same as the previous solution sans the extra package release, and also popular.
- Release your package on your own index server, and use
--index-urlto override pypi.org on installation. It is quite trivial to build and run your own package index (see devpi), and there are multiple out-of-the-box solutions if you’re willing to pay. The downside is that your users need to explicitly specify your index to get your packages, but that’s a good thing IMO because they are getting a different package from normally expected.
What choice is best mainly (IMO) depends on why you’re forking the depended package in the first place. PyPI’s restriction is intended to prevent package users from installing from an unexpected source (if I install from PyPI, I can guarentee all my install packages are from PyPI), and each solution offer a different explaination to the user why they are installing a non-PyPI source.