3

I have 2 Heroku apps, both Pyhon, and some python modules that are shared between them (i.e.: they are the same in both apps). What is the best way to set up my git / requirements.txt to achieve the following?

  1. The shared code is versioned (that is: it too sits in Git, I don't care where -- one of the projects? Another project?)
  2. In development, I have a single copy of that shared code on my disk
  3. In development, I can change that single copy of the shared code and have the change reflected in both apps, ideally without doing anything other than changing files on disk.
  4. When pushing to Heroku, all I do is a simple "push"

My gut feeling tells me I need to have the shared code as a Python package, on disk, and in development add it to each app's PYTHONPATH. Further, I would add it (how? using a private server? from s3? as a vendor dir?) to the requriments.txt on each app.

... but I can't quite nail it.

Any thoughts?

Nitzan Shaked
  • 13,460
  • 5
  • 45
  • 54

3 Answers3

4

You can use pip requirements files to do that. You may have one for local development and one for your apps. Please check out the requirements file format for more info.

Local development requirements file

file:///path/to/your/lib/project#egg=MyProject

This should give you readonly access from your app, which is useful for shared code (e.g. git clone of a project). Please note that it will point to HEAD. This should fit requirements 1, 2, 3.

For the project layout, you can check out the setuptools documentation; e.g. create a setup.py and a package with your code in it. You can look at the requests library which is a good example.

App requirements file

git://git.myproject.org/MyProject.git#egg=MyProject

This should pick up whatever code you pushed to your repo. I don't have experience with Heroku, but if they support requirements file that should just work. This should fit requirement 1, and I hope 4.

If you want to use private git repo with heroku, please refer to heroku documentation (please note that it is username:password basic auth and does not have email address). If you don't want to use a password you can use a revocable OAuth token.

Community
  • 1
  • 1
dnozay
  • 23,846
  • 6
  • 82
  • 104
  • Could you please add comments/edits re: (1) the project layout on local disk, in development mode? (do I edit the "installed" files? what's the process of re-packaging after changing?) (2) how to set up a repository so that I don't have to have my github credentials in the URL that's in requirements.txt – Nitzan Shaked Jan 19 '13 at 05:25
3

You should use Git Submodule.

You create one project where your code resides and then add references to this to your two Heroku apps.

Thorsten Kranz
  • 12,492
  • 2
  • 39
  • 56
  • The issue with submodule a is that it'a error prone, as far as I can tell. I find a lot of criticism on the net. Plus, it doesn't satisfy points 2 and 3 on my wish list. If there's no other way I may use it, I suppose, but I will first checkout per options such as custom scripts, eg. What about my half baked suggestion? Is it any good? – Nitzan Shaked Jan 10 '13 at 12:56
  • I found it to be quite useful. – Thorsten Kranz Jan 10 '13 at 12:58
  • Heroku is based entirely on push events. That makes me question whether Heroku would detect and then pull the submodules. If not, then all you have are some useless references in `.gitmodules`. Using a `requirements.txt` is the way to go here. – Ian Stapleton Cordasco Jan 20 '13 at 04:12
  • "GitHub repos that use submodules will generally not deploy correctly on Heroku. This is because GitHub does not include submodule contents when repo-content tarballs are generated." - See https://devcenter.heroku.com/articles/github-integration#git-submodules – mbreining Aug 07 '15 at 00:06
1

One more idea is to dig into Git Subtree Merging.

You can have your common module as a branches in both your repositories, pointing to common origin. And then you could put it into your project folder.

shytikov
  • 9,155
  • 8
  • 56
  • 103