Don't think too much about Pip. If your Setuptools configuration works correctly, it's easy enough to upload all and only those files you actually want to PyPI (at which point end users will be able to install it with Pip; developers will be cloning your git repository since they need history for things like git bisect to work, and Pip does not provide git history).
Worry instead about how your project will be laid out. One common layout is something like this:
Root directory
|
+- name-of-your-project/
| |
| +- __init__.py
| |
| +- other modules and packages...
|
+- name-of-forked-dependency/
| |
| +- __init__.py
| |
| +- other modules and packages...
|
+- setup.py
|
+- Other stuff...?
"Other stuff" might include documentation, unit tests, and other miscellaneous materials which you do not want to distribute alongside your code. It is also somewhat common to put a requirements.txt file here as a hint to developers that they should install certain packages in order to work on your project. Note that Setuptools is smart enough to include some files but not others, so you can just put most of these files directly alongside the source code if that is your preference.
The next question is how you get the repository to look like this while preserving the history of your forked dependency. Assuming the other project follows the Python standard of keeping its own code in a directory named after its root package, you have two options:
- If your code already exists and has history, you may want to create a git repository with two roots. One root will be the initial commit of your code, and the other will be the initial commit of the code you are forking. So far as I can tell, this appears to be doable by simply doing a
git remote add and then a git fetch on the new remote. Afterwards, you probably want to merge the branches together with git merge, at which point you will have a single master branch with all of the history from both repositories.
- If your code does not yet have history, this is even easier: Just clone the repository you want to fork, change the
origin to something sensible such as a newly-minted GitHub repository, push, and begin development.
The above assumes you want to distribute your forked copy of the code as a unit alongside your actual project. It may be more sensible to distribute them separately and list the fork as a dependency of your code in the Setuptools configuration. That way, you can maintain two separate repositories for each of them, and provide a separate package on PyPI for people who just want to work with your forked code. Developers who want to contribute to both repositories will have to do slightly more work, however, so you will need to judge the benefits and drawbacks yourself.
For completeness, you should also be aware of the Virtualenv tool, which is invaluable for managing complex dependency situations such as yours, and is also quite suitable for even the simplest of deployments.
