Maintaining 3rd Party Django Apps as Git submodules

Question

I know this is perfectly possible and a lot of people already doing it, but my problem is slightly different and I couldn't figure out the solution yet:

Let a 3rd party Django App's structure as below:

• django-module
  • module
    • init.py
    • views.py
    • models.py
  • requirements.txt
  • setup.py

I want to bundle only the module directory as a submodule, because then I can access views.py file just by typing "module.views". If I import the django-module directory, I would have to write django-module.module.views to access the module files, which is not feasible.

My purpose is to modify the module and make pull requests occasionally to the original repository. Is there workflow that I can follow, or what are the best practices for this purpose?

Answer 1

The best practice is to keep the submodules exactly as they are.

Once you've added a 3rd party module to your app as a submodule, the next step is to make sure you add that "django-module" directory to your python path. As long as django-module is on your python path, you will be able to use the submodule as you usually would by typing "module.views" as you wish.

Answer 2

Pip tips

Pip has support for editable packages and retrieving packages with git, so you could create a virtualenv, use pip to install the packages, and update them using pip when you want.

So you could add:

-e git://git.myproject.org/MyProject.git@da39a3ee5e6b4b0d3255bfef95601890afd80709#egg=MyProject

To your requirements.txt to retrieve that exact commit.

---

Suggested workflow

I think that the best way to solve your issue is the following:

• Make a private fork of the package
• Edit the package in a specific development branch in the forked repository

• Use the package from your fork's development branch in your requirements file.

• When you feel like it, update the forked package where you're using it using pip.

• When you're ready to make a pull request, pull origin, rebase your working branch to origin/master, and make the pull request from the master branch of your fork.

This means you have three places where the code is present:

• The original repo (where you don't have access)
• Your forked repo (where you work on your fork)
• Wherever pip installed it (where you use your fork)