Since some assumptions were met, I decided to switch the main environment to Python 3.4. Below, about writing notes.
Until now, I used to install with homebrew-> create virtualenv, but this time I decided to build it myself. There is no formula to install by specifying minor versions such as python31 and python32, and there was a fear that the existing main environment Python 3.3 might be deleted by the update. (It is unconfirmed whether it actually is)
python
% brew search python3
python3
Clone the source from github. Https://github.com/python/cpython
python
% git clone https://github.com/python/cpython
% cd cpython
Specify the installation directory with configure. You can leave the default (/ usr / local), but in that case use make alt install instead of make install to avoid overwriting existing symlinks.
(ref.) https://github.com/python/cpython/blob/master/README
bash:Python3.4.0 installation
% ./configure --prefix=~/python/python34/3.4.0
% make
% make install
% ls ~/python/python34/3.4.0/bin/
2to3 2to3-3.4 easy_install-3.4 idle3 idle3.4 pip3 pip3.4 pydoc3 pydoc3.4 python3 python3-config python3.4 python3.4-config python3.4m python3.4m-config pyvenv pyvenv-3.4
In my own environment, I am building a virtual environment for each version without changing the system default Python (2.7.5). It is common to use virtualenv to create a virtual environment, but starting with Python 3.4 you have the option of using the standard library pyvenv. https://docs.python.org/3.4/using/scripts.html#scripts-pyvenv
I can't say for sure because I've only tried it lightly, but if I just replace the virtualenv, there seems to be no problem. However, virtualenv has a nice utility called virtualenvwrapper, so I'm not going to migrate pyvenv unless this is resolved in some way. (Although it has been pointed out that you should implement it yourself or Gorua ...) However, I think the significance of being able to build a virtual environment with the standard library is huge. Expectations for the future.
virtualenv(wrapper)Virtual environment construction in
% mkvirtualenv -p ~/python/python34/3.4.0/bin/python3.4 py3.4.0
…
(py3.4.0)% python
Python 3.4.0+ (default, Apr 19 2014, 14:38:58)
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.2.76)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
Keep this main environment as clean as possible, but only include iPython. It's inconvenient when you want to check something without it. Since virtualevnwrapper supports hooks when creating a virtual environment, use it. The operation after creating the virtual environment can be defined by the postmkvirtualenv file, so write the process to install ipython here.
postmkvirtualenv
#!/bin/zsh
# This hook is run after a new virtualenv is activated.
pip install ipython
(ref.) http://virtualenvwrapper.readthedocs.org/en/latest/scripts.html
I also included httpie because it's convenient.
python
(py3.4.0)% pip install httpie
In the current situation, you have to specify the use of the virtual environment created by entering the following command every time you start the terminal.
python
#workon is provided by virtualenvwrapper
% workon py3.4.0
(py3.4.0)%
This is inconvenient, so be sure to work on when you log in. The following is the premise of using zsh.
~/.zlogin
% cat ~/.zlogin
#Give regularity to the names of virtual environments.(py + (version))
#The default version is managed as a separate file
if [ -f ~/.venv/.defaultver ];then
DEFAULT_VER=`cat ~/.venv/.defaultver`
workon py${DEFAULT_VER}
fi
% cat ~/.venv/.defaultver
3.4.0
(ref.) http://qiita.com/yuku_t/items/40bcc63bb8ad94f083f1
Normally, the above virtual environment is used, but as mentioned above, I want to keep the main environment clean, so I will create a virtual environment for each project from here.
Since Python 3.4.0 is set to be used by default, it is basically not conscious of where the specified interpreter is (can be specified with = \ which python).
python
(py3.4.0)% mkvirtualenv -p `which python` new_project
Recommended Posts