As a quick check, I'd suggest replacing
~/code/packages/install
with
/full_path_to_your_user/code/packages/install
As a quick check, I'd suggest replacing
~/code/packages/install
with
/full_path_to_your_user/code/packages/install
If you just want it in your home directory, there's no need to install it at all. Just make sure that the container directory is on your pythonpath somewhere, and move the scripts in django/bin into somewhere on your main PATH (or add that dir to your path).
I would strongly suggest that you look at Virtualenv and Pip for creating basically silos of python packages.
The Pinax project uses this exclusively now for bundling requirements together for other people to use, and it's becoming more and more of a defacto standard in the reusable apps space.
Ok, so I've been looking at the distutils source code to see what is going on - distutils.command.install
does all of the pathname manipulation.
It turns out that the documentation is actually incorrect. Whenever an --install-xxxx style option is provided it completely overrides any value that might be derived from --home
or --prefix
- the code not does do any straightforward concatenation of paths.
However, what it does do is variable substitution of a set of special variables. The one of interest to me specifically is $base
. Using it on the command line you can define the overrides, and distutils will replace all occurrences with what was specified for --home
etc. But note you must quote your filenames so BASH does not try expand it as a environment variable.
So the command line that I had initially, becomes:
python setup.py install --home=/home/andre/code/packages/install --install-purelib='$base/modules' \
--install-platlib='$base/modules' --install-scripts='$base/scripts' --install-data='$base/data'
Hope someone other than me finds that useful!