I need to maintain parallel versions of python2 and python3...
Closed this issue · 17 comments
...so just using 'pip' to install things in the script instead of pip2/pip3 is going to be An Issue. I don't have the bandwidth to fix this right now so I'm just opening an issue instead of a pull request.
Thanks,
Kat
both my python2 and python3 come from homebrew on 10.10
You are right. Should be reasonably straightforward to generalize the script. I'll try to have a go at it tonight.
Give #60 a try and see if it fits the bill. Feel free to edit.
Sorry for the late response, my life got kind of chaotic...
I edited it a bit: https://github.com/crowsonkb/ScipySuperpack/commits/dual_python
I'm a bit paranoid about the invocations of python and easy_install on lines 70 and 71... should those be python3/easy_install-3.4 in the python3 case? I'm also slightly paranoid about testing this on my actual main homebrew installation in /usr/local/bin so I tried to adapt the script a bit to work in a contained temporary homebrew environment but I failed at that... So I haven't actually tested it yet. :(
This is totally breaking. I tried removing my homebrew installation entirely and running the normal version of the script to see if it even worked and it didn't because you don't get a 'pip' command if you select python3 in the normal version, you get pip3...
currently wiping my entire homebrew installation and then installing python3 only from the dual_python branch to try and get my dev environment back into a sane state. this script interacts with homebrew in very weird ways and if you're thinking about making it homebrew-based maybe you should turn it into some sort of homebrew metapackage that installs all the stuff it needs. and then have the homebrew-installing script as an outer layer that checks if brew is present and if so installs your metapackage etc.
and then nifty things might become doable like installing contained versions of the superpack in a separate directory or including parts of the superpack in .app bundles easily, because if it's integrated with homebrew like that then you get homebrew's capabilities of that sort as well. anyway, i think gfortran finished building so i'm going to check on the progress of getting a python3 superpack dev env installed
fail.
creating dist
creating 'dist/numpy-1.10.0.dev_31b94e8-py2.7-macosx-10.10-intel.egg' and adding 'build/bdist.macosx-10.10-intel/egg' to it
removing 'build/bdist.macosx-10.10-intel/egg' (and everything under it)
error: can't create or remove files in install directory
The following error occurred while trying to add or remove files in the
installation directory:
[Errno 13] Permission denied: '/Library/Python/2.7/site-packages/test-easy-install-79015.pth'
The installation directory you specified (via --install-dir, --prefix, or
the distutils default setting) was:
/Library/Python/2.7/site-packages/
this was with the script from the dual_python branch, selecting python3, because it was somehow trying to install numpy to 2.7 still. giving up.
well, i got my homebrew+python2.7 dev environment back into working order. i'll need to install the python3 stuff manually i guess.
Well, that all sounds pretty miserable. The Superpack script as written is intended to work with Homebrew's Python, partly to avoid the permissions issue that you have run into.
Unfortunately, if you use the dual_python branch to install python3 first, or only python3, then I'm not sure you get a /usr/local/bin/python (just a /usr/local/bin/python3), so lines 70-71 here: https://github.com/fonnesbeck/ScipySuperpack/blob/dual_python/install_superpack.sh#L70 will try to install the newly-built numpy using /usr/bin/python into /Library/Python/2.7/site-packages, which will fail. (Also, how does this know to install numpy into the homebrewed python3 site-packages directory? It seems like it would just install into the homebrewed 2.7 directory still!) This issue may exist with the master branch too. Eventually I had to install homebrewed python 2.7 using your script and then bring up the python3 dev env in parallel beside it.
Oh yeah, eventually I did get the entire stack working on both homebrewed python2 and homebrewed python3, but I had to do the python3 part manually. I mean the ipython3 notebook, things I use that depend on the stack like the http://colour-science.org library, and all.
I think it would really be best to always explicitly call the python2/python3 binary that the script intends to use by its full path including the major version, (i.e. /usr/local/bin/python[n]), as well as the full path to the correct easy_install binary. That way you can be sure of never accidentally using the system python.
Idea for further development: reference brew as /usr/local/bin/brew, or at least have a global variable set to /usr/local/bin (i.e. rename PIP_PATH to something more general) and call all of brew, easy_install, python2/3, pip2/3 by prepending this variable. Then if anyone ever wants to bring the stack up in a homebrew location that isn't in /usr/local/bin, all they'd have to do is edit this one variable...
I have a new work-in-progress super-paranoid version of the dual_python branch in testing:
Notes:
- I have tested this in a custom homebrew directory with python3 only so far. It seems to work in that configuration (my tests so far have included bringing up the ipython notebook interface, plotting a few things, doing some basic numpy sanity checks, and installing colour-science and displaying a few of its demo plots).
- The entire set of options in
set -euvxmay not be required. The last two are for debugging help. However I would strongly recommendset -euat the bare minimum. - Many of the paranoid things I am doing, like setting
readonly, using[[exclusively, and being fanatical about"${VAR}"in variable expressions, come from the Google shell style guide. - The
export PATHon line 28 is required for later build scripts when using a custom homebrew directory and should be harmless at worst ifBREW_PATHis/usr/local/bin.
Super-paranoid is probably good. Feel free to create a pull request if you are happy with it.
💖