Python / Git / Module structure best practice
We have a lot small projects that share common utility “projects”
utility project math contains function add
project A and project B both need math.add
project A has nothing to do with project B
- Does Repository.walk traverse all commits
- Deploying a local django app using openshift
- How can I save my secret keys and password securely in my version control system?
- Sharing Python code between Heroku apps
- Decompile *.pyc file using uncompyle2
- Gitpython ssh password
so is it a good idea to have 3 git repositories (project_A,project_B and math) and clone them locally as
and have in /SOMWHERE/workspace/project_A/__init__.py something like
import sys sys.path.append('../math') import math math.add()
I have read Structuring Your Project but that doesn’t handle SCM and sharing modules.
So to sum up my question: is
sys.path.append('../math') import math
good practice or is there a more “pythonic” way of doing that?
2 Solutions collect form web for “Python / Git / Module structure best practice”
Submodules are a suboptimal way of sharing modules like you said in your comments. A better way would be to use the tools offered by your language of choice, i.e Python.
First, create virtualenvs to isolate every project python environment. Use pip to install packages and store dependencies in a
Then, you can create a specific package for each of your utils library using distutils and share it on Pypi.
If you don’t want to release your packages into the wild, you can also host your own Pypi server.
Using this setup, you will be able to use different versions of your libraries and work on them without breaking compatibility with older code bases. You will also avoid using submodules, that are difficult to use with git.
all of what you describe (3 projects) sounds fine except that you shouldn’t mess around with
sys.path. instead, set the
PYTHONPATH environment variable.
also, if you were not aware of distutils i am guessing you may be new to python development, and may not know about virtualenv. you should use that too (it allows you to develope against a “clean” python version that has no packages, or only the packages you install for that env).