How can i install Sqitch on Centos 7 offline - centos7

In my client Centos 7 machine in need to install sqitch, but in offline environment have no clue how to do that!

Found a solution which worked for me, where i am trying to generate a Sqitch bundle folder which we will have a working build of Sqitch which you can use in other centos 7 machines having the same Arch.
# yum install gcc
# yum install perl-DBD-Pg
# cpan
cpan[1]> install HTML::Entities
Extract tar
# cd /{extracted_dir}/
# perl Build.PL
# ./Build installdeps
# ./Build bundle --install_base sqitch_bundle --dual_life 1 --with postgres
Now you have sqitch_bundle folder inside App-Sqitch-v1.0.0 folder which got extracted in the above step, this sqitch_bundle folder you can tar it and share with other Centos 7, having Perl enabled."
After which, Sqitch can be run from
# ./sqitch_bundle/bin/sqitch
Now to access as regular we need to add the Path in .bashrc or .bash_profile, Example
PATH="/opt/App-Sqitch-v1.0.0/sqitch_bundle/bin/:$PATH"

Related

installing php-imap on amazon ec2 linux 2

I need to install php-imap on amazon ec2 linux 2 instance.
All the php stuff is inside amzn2extra-lamp-mariadb10.2-php7.2 but php-imap package is missing.
Any advice ?
Thanks
I installed it like this.
I downloaded the php source code of the currently installed version in my Amazon Linux 2
wget http://php.net/get/php-7.2.8.tar.bz2/from/a/mirror
Unpacked it and went into php-7.2.8/ext/imap/
Compiled extension:
phpize
./configure
I got some errors.
Some U8T_CANONICAL stuff so
sudo yum install libc-client-devel
Then libc-client.a not found so created a symlink for it:
cd /usr/lib
sudo ln -s /usr/lib64/libc-client.a
some other imap library error so:
sudo yum install uw-imap-static
I got some other errors so the working configure line was:
./configure --with-kerberos --with-imap-ssl
make
SUCCESS!
cd php-7.2.8/ext/imap/modules
sudo cp imap.so /usr/lib64/php/modules/
Created an ini file to load it:
sudo vi /etc/php.d/30-imap.ini
added to the file this content:
extension=imap
restarted php service (you might need to restart httpd depending on your php installation):
sudo systemctl restart php-fpm
PHPinfo now contains:
imap
IMAP c-Client Version 2007f
SSL Support enabled
Kerberos Support enabled
For those who are facing the U8T_CANONICAL error and can't being able to install the libc-client-devel on Amazon Linux 2 AMI need to do something extra to resolve the U8T_CANONICAL error.
The main problem is that libc-client-devel isn't available so we need to do it in another way.
I found this link while searching for my problem. The solution that is posted here is solid. The following link that i gave is for those who are not being able to install the libc-client-devel will be benifited from the link.
Or you could just copy paste the commands i'm giving below.
1 - sudo yum groupinstall "Development Tools"
2 - sudo amazon-linux-extras install epel
3 - yum install epel-release
4 - sudo yum install libc-client-devel uw-imap-static openssl-devel
5 - sudo ln -s /usr/lib64/libc-client.a /usr/lib
The rest can be followed from respondent.
Again thanks to the person who answered.
Same problem here.
I came from debian/ubuntu and i miss a lot of php packages on aws linux2.
I know it's still a candidate and not a final LTS release. Only worked for a month with this distro and saw a lot of changes and updates. Some php dependencies can be solved with pear or pecl, but I couldn't get nothing working on php-imap.
php-imap depends on libc-client (maybe that's a problem?)
Here is my solution.
Search for the libc-client rpm that correspond to your version and
install manually.
Search for the rpm that corresponds to your php installed version. In my case it was 7.2.5**-2** about 2 weeks ago. (today is
7.2.5**-3** ) and isntall manually
CODE
wget https://dl.iuscommunity.org/pub/ius/stable/CentOS/7/x86_64//php72u-imap-7.2.5-2.ius.centos7.x86_64.rpm -P /tmp
wget http://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/l/libc-client-2007f-16.el7.x86_64.rpm -P /tmp
rpm -i /tmp/libc-client-2007f-16.el7.x86_64.rpm
rpm -i /tmp/php72u-imap-7.2.5-2.ius.centos7.x86_64.rpm
If it fails because Failed dependencies:
rpm -ivh /tmp/php72u-imap-7.2.5-2.ius.centos7.x86_64.rpm --nodeps
I dont like this solution, but can't find for now any other solution more stable and easy. It will be a pain with updates....

AWS cli installation on Mac with anaconda python

I am installing aws cli on Mac. Previously I installed anaconda to control my python versions. So I installed python using conda. Now I want to install aws cli.
By using pip:
pip3 install awscli --upgrade --user
The installation was successful. However, when I run
aws --version
It told me that aws command was not found.
I again tried to add it to the command line path. But I could not find where it was installed.
When I run
which python
It gave me
/anaconda/bin/python
People say this might not be the real folder and it is true I could not find aws cli under it either.
I then run
ls -al /anaconda/bin/python
It gives
lrwxr-xr-x 1 mac staff 9 Aug 15 20:14 /anaconda/bin/python -> python3.6
I dont understand the path at all.
How could I find where my aws cli installed?
I ran into the same issue and eventually found the awscli command in ~/.local/bin. Just add /Users/<username>/.local/bin to your $PATH.
You can do this by editing ~/.bash_profile, which probably already has these lines in it:
# added by Anaconda3 4.4.0 installer
export PATH="/Users/<username>/anaconda/bin:$PATH"
You could make another copy of this line but replace the anaconda path with the new one, but I just updated the existing path since the two are related:
# added by Anaconda3 4.4.0 installer
export PATH="/Users/<username>/.local/bin:/Users/<username>/anaconda/bin:$PATH"
I solved the problem by using conda to install awscli.
conda install -c conda-forge awscli
worked so far. It seems that pip install does not work for conda installed python... Is this conclusion true?
If it's installing and then saying "command not found" it probably just means that the executable it has installed is not referenced in the operating systems PATH environment variable.
Here is how to add the downloaded executable to PATH: https://docs.aws.amazon.com/cli/latest/userguide/cli-install-macos.html#awscli-install-osx-path
Here is the AWS docs to troubleshoot the issue: https://docs.aws.amazon.com/cli/latest/userguide/troubleshooting.html
I encountered an identical situation.
I solved this by adding the location of the awscli command to the file...
/etc/paths
The location to my awscli command was where others had found it...
~/.local/bin
From my home directory in Mac OS X Terminal, I entered a quick nano command to edit the /etc/paths file...
sudo nano /etc/paths
#For those who don't know...
#sudo is to get admin access
#nano is quick and dirty file editor.
# /etc/paths is the file you want to edit.
I entered my password, then I just added the awscli command location at the end of the file...
/Users/UpAndAtThem/.local/bin
Yours might be be...
/Users/your_username_here/.local/bin
Still in Nano editor to exit and save: Hit control+X > Hit Y > Hit Enter.
Here's a quick video...
https://youtu.be/htb_HTwtgmk
Good luck!

not able to install contextBroker via yum on CentOs7

HI everybody i am using CentOs7 and havae some troubles with the installation of the contextBroker. I followed the installation on the added the Fiware Repo in my yum repo.
Here is a list of my yum repo:
repo id repo name status
base/7/x86_64 CentOS-7 - Base 9,007
epel/x86_64 Extra Packages for Enterprise Linux 7 - x86_64 10,368
extras/7/x86_64 CentOS-7 - Extras 356
fiware Fiware Repository 176
mongodb MongoDB repo 279
updates/7/x86_64 CentOS-7 - Updates 2,070
repolist: 22,256
I am always getting an error message that there are some failed dependencies
libboost_filesystem-mt.so.5()(64bit) is needed by contextBroker-0.15.0-1.x86_64
libboost_system-mt.so.5()(64bit) is needed by contextBroker-0.15.0-1.x86_64
libboost_thread-mt.so.5()(64bit) is needed by contextBroker-0.15.0-1.x86_64
Here is the output of my config file for the fiware.repo
[fiware]
name=Fiware Repository
#baseurl=http://repositories.lab.fiware.org/repo/rpm/$releasever
baseurl=http://repositories.lab.fiware.org/repo/rpm/x86_64/
gpgcheck=0
enabled=1
I found a possible solution under this link, but unfortunately this is not working. In the comment section there is an entry which says that there is a problem with CentOs7 but that doesn`t solve my problem
Btw: this is also not working Boost-Libboost is needed in Centos7 (ContexBroker)
So my question is, did someone installed the contextBroker on CentOs7 via yum and if he/she did how can i solve this problem ?
As you mention, there isn't official support for CentOS 7 at the present moment. However, you could do the following to get a running binary with contextBroker in your CentOS 7 system (actually, this a "quick and dirty" receipt based on the build from sources procedure documented in the Orion manual):
sudo yum install git wget
wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
sudo rpm -i epel-release-latest-7.noarch.rpm
sudo yum install make cmake gcc-c++ scons
sudo yum install boost-devel libcurl-devel gnutls-devel libgcrypt-devel libuuid-devel
# Install mongoDB driver as described in the documentation
# Install rapidjson as described in the documentation
# Install libmicrohttpd as described in the documentation
mkdir ~/src
cd ~/src
git clone https://github.com/telefonicaid/fiware-orion.git
cd fiware-orion
# optionally, you can set an specific version with a checkout command
# e.g. 'git checkout 1.2.1'. Otherwise, you will build the latest
# code from develop branch
make
BUILD_RELEASE/src/app/contextBroker/contextBroker --version
Moreover, you can use the following to generate a RPM file:
sudo yum install rpm-build
make rpm
# The RPM is generated in rpm/RPMS/x86_64/contextBroker-1.2.0_next-dev.x86_64.rpm
# (version number may vary)
That RPM file is supposed to work in other CentOS 7 systems and you can install just using sudo yum install /path/to/contextBroker-1.2.0_next-dev.x86_64.rpm.

How to get Django 1.7 working on Ubuntu 14.04 with nginx and virtualenv using python 2.7 while having python 3.4 installed?

I am a newbie to Django and Python installation. Intermediate with Ubuntu 14.04.
These are my installations so far in my Ubuntu 14.04.
apt-get install python3-setuptools --force-yes -y ## for python3
easy_install3 pip ## for python3
apt-get install python-setuptools --force-yes -y ## for python2.7 or above
easy_install pip ## for python2.7 or above
apt-get install python-dev --force-yes -y ## because ubuntu 14.04 does not have dev version of python 2
apt-get install python3-dev --force-yes -y ## because ubuntu 14.04 does not have dev version of python 3.4
apt-get install links --force-yes -y ##a command line web browser
apt-get install python-flup --force-yes -y ## connects python to uwsgi)
apt-get install build-essential --force-yes -y ##
pip2 install django uwsgi virtualenv ## use pip to install django and uwsgi and virtualenv for python2
pip3 install django uwsgi ## use pip to install django and uwsgi for python3
For the full list, please look at https://gist.github.com/simkimsia/41c55e0c08eda42e2cb3#file-install-sh-L88
I am confused about the use of virtualenv.
I want to prepare my ubuntu 14.04 server edition for a production level of Django 1.7 as much as possible.
The reason why I installed multiple Python environment because I may have other Python apps running which require 3.4.
My Django files are from bitbucket repository and I have git cloned them into /var/virtual/WebApps/DjangoProject
Inside /var/virtual/WebApps/DjangoProject, I have manage.py and other files and folders.
Please advise on how do I get the Django project running for this situation.
I am currently testing this setup on my virtualbox and vagrant.
EDIT
There will be at least 2 Django applications. 1 requires 2.7 python. The other requires 3.4 python.
Let me add that this is a single server that will host the application, frontend, and database.
EDIT 1
I have restarted with a fresh install of Ubuntu 14.04 and I started with Python 2.7.6 and Python 3.4.0.
I then did sudo apt-get install python-virtualenv which I checked its version: 1.11.4.
I have created ~/virtualenvs/py2.7 and ~/virtualenvs/py3.4.
Inside ~/virtualenvs, I did virtualenv -p /usr/bin/python2 py2.7
and ~/virtualenvs, I did virtualenv -p /usr/bin/python3 py3.4
So how do I install python2 only libraries for the python 2 app?
E.g. are django-adminfiles, sorl-thumbnail, psycopg2
EDIT 5
Use virtualenv --system-site-packages -p /usr/bin/python2 py2.7 instead
I have restarted with a fresh install of Ubuntu 14.04 and I started
with Python 2.7.6 and Python 3.4.0.
Okay, so now in your system you have two base versions of Python. Base version just means, the versions that are supported by your operating system; which you have installed globally.
In other words you have installed them using the operating system's package installers and did not compile them separately.
In practice, this above only matters in Linux, because in Windows you cannot install "locally" without going through a few hoops; all Python installers will register themselves in the registry thus making them global, base Python versions.
I then did sudo apt-get install python-virtualenv which I checked its
version: 1.11.4.
This package is outdated (current version is 12.0.7).
Now you have virtual environment installed against the base Python 2 version because the package requires Python 2.
In practical terms it means if you need to upgrade Python 2, you'll have to make sure python-virtualenv is also updated for the base versions of both Pythons that are supported by your operating system. This means, when you apt-get update and apt-get upgrade, virtualenv will be upgraded.
Usually this doesn't matter as its a rare case if python2 is upgraded and then python-virtualenv is not upgraded to match its dependency.
However this is not recommended because you want to control the versions of critical software "manually" to avoid any surprises. There are ways to control this on Ubuntu and other debian-like distributions by pinning versions; but even if you do so, you may not be getting the latest version of the library which may force you later on to uninstall the version that came with your operating system, and reinstall it from source.
I have created ~/virtualenvs/py2.7 and ~/virtualenvs/py3.4.
Inside ~/virtualenvs, I did virtualenv -p /usr/bin/python2 py2.7 and
~/virtualenvs, I did virtualenv -p /usr/bin/python3 py3.4
So how do I install python2 only libraries for the python 2 app?
E.g. are django-adminfiles, sorl-thumbnail, psycopg2
In order for solr-thumbnail and psycopg2 to be installed correctly, you need to build their dependencies; so
sudo apt-get install libjpeg62 libjpeg62-dev zlib1g-dev
sudo apt-get install libgraphicsmagick++-dev libboost-python1.55-dev
sudo apt-get install libexpat1-dev libpython-dev libpython3-dev libssl-dev libpq-dev
To install libraries for the Python 2 app:
Activate the virtual environment; by typing source ~/virtualenvs/py2.7/bin/activate
Type pip install _____ (name of the library)
To support multiple Python applications with different major versions; your system should have both Python major versions installed (you already have done this).
You then install virtualenv for each Python major version. You can skip this step if your applications are fully contained (that is, they include the Python runtime required - but this is a rare case) or if you have a single purpose server.
You should avoid installing anything but the base Python libraries in your system's global python. That is avoid (as root, or using sudo) to pip install things; because these will be installed for all users of Python and may cause problems (on some systems; like Fedora/RedHat - critical system packages like yum rely on the base system Python).
Next step is to make sure you have a suitable build environment available. This means for Debian-sourced systems to install build-essential and further the support libraries for common Python drivers and modules. The exact libraries you need to install will depend on the applications you are planning to host, but at a minimum you should make sure PIL (or Pillow) can be installed and database drivers' support libraries are available. To do so, you can apt-get build-deb python-imaging psycopg2 python-mysqldb (for PostgreSQL, MySQL and PIL).
Now you have a system ready to support most Python applications. You can then optionally add other utilities, but I would try to avoid assuming too much about what applications will require.
To host an app:
Create a virtual environment with the base version of Python required. So virtualenv-2.7 or virtualenv-3 as the normal non-root user account.
Install required packages into the virtual environment.
Adjust the bootstrap script for your application to use the correct Python binary. This is usually done from whatever process you are using to manage your application server. For example, on my server I use supervisord.
That's all you have to do. Everything else will depend on the individual application's requirements and setup (so if you need to serve static files, you'll have to configure that mapping, etc.)
After reading your shell script, it seems you are trying to build a server that will support both the application, the front end and the database.
In order to support such a system; you will need to install the following:
Database server(s) that you would like to support. As this is a single purpose server, you will also need to install database command line clients.
Source code tools (git, etc.)
A global process manager (like supervisor or circus).
Base Python versions you intend to support; and their development headers (sudo apt-get install python-dev)
setuptools, pip, and then virtualenv. These tools should be installed from source rather than your package manager; to ensure the latest versions are installed. You should install these globally (ie, as root) so they are available for all users.
A build tool chain (ie, "Development Tools" or build-essential)
Support libraries for any extensions (but not the extensions themselves). The easiest way to do this is to use the package manager to build the dependencies and not the packages sudo apt-get build-dep python-imaging psycopg2 python-mysqldb.
The next thing you need to do is decide how you will run your application servers (the "django code"). You can use uwsgi, gunicorn, etc. as these are the ones most tested with django.
You need to be able to support multiple versions of these runtimes, so instead of installing them globally across the system; just build their dependencies and install the specific version required for each application in its own isolated environment.
The next thing you need to install is a front end proxy for your applications. You can install whatever proxy suits your needs (nginx is the most popular); but please install from source rather than the packages as those are almost always out of date.
Once all this is setup, the process of hosting a django application is the following:
Create a separate user account with a non-login shell.
Create a virtual environment in this user's home directory. I recommend keeping some standard here, like env for the virtual environments.
Download/copy the source code of your application.
Create a standard directory where you will store the static files. For example I use $HOME/www/static.
Create an entry in your process manager.
Create an entry in your proxy for front end routing.
Reload your proxy server.
Reload your process manager.
You can automate/script a lot of the above. For example, you can create a custom skeleton directory to create the base directories for you when adding new users; and you can create custom templates for other areas using tools like cookiecutter.
Understanding execution path
The first principle to understand is that when you install packages on your operating system (virtual machine, whatever) with sudo is that you are installing all those packages in a global location, that is, a file directory which your system knows about via the $PATH (PATH) environment variable.
This $PATH variable is often set-up by default in your .bashrc or your .bash_profile or your .profile whenever a new linux/unix user is created. Whether you have any of these files depends on what is inside the /etc/skel on your system. /etc/skel holds a "template" of these files that gets duplicated whenever a new user with a home directory is created.
When you type echo $PATH in command line, you would see a list of execution search path delimited by :, for example:
/usr/local/sbin:/usr/local/bin:/usr/bin
This is an example I will use for the purpose of this discussion. Different OS will give you slightly different default $PATH but the simple idea here is that the binaries of your globally installed packages gets thrown into one of these directories and the reason you are able to run these binaries is because these binaries (programs) are now available in the execution search path (simply called $PATH).
Ok great, but what does this mean for the python 2 and python 3 interpreters I installed?
So in relation to your question, this means that when you sudo apt-get or sudo aptitude install python2 or python3 binaries (python interpreters), they are both available and to differentiate which interpeter you are using at any moment, you would run python2.7 or python3.4 that correspondingly calls /usr/bin/python2.7 or /usr/bin/python3.4
You can always check this easily by using the which linux/unix command. which python3.4 will return you the exact path where your python3.4 binary is installed.
Similarly, when type pip2.7 in your command line, you are asking your system to execute the pip2.7 program that came installed with your python2.7 package. And naturally which pip2.7 will reveal to you where this pip2.7 binary has been installed.
All this is possible simply because these binaries are have been installed by you using sudo apt-get and are placed in the directories listed in $PATH. If you move one of these binaries forcibly to another directory not listed in $PATH, you will realize that you can no longer run the binary in your command line without typing out the specific path to the binary.
Additional python specific information
The Python Interpreter has another attribute call $PYTHONPATH. This - as you will rightly deduce - is a variable that holds a list of directories ("search path") where the python interpreter will search for python modules to load. If you want to know where your python interpreter is currently looking for modules (your own python modules or 3rd party python modules), run
python -c "import sys; print(sys.path)"
where python is your specific python interpreter. If /usr/bin/python is symlinked to /usr/bin/python2.7, then you are in fact calling python2.7.
When would python path matter? It matters inside your own .py source code when you ask to import other modules. The import line of code in your .py source code is where you are asking the python interpreter to go forth and search for the module that you want to import. As you can imagine, if your sys.path (in python) is empty, you will not be able to import any 3rd party modules.
Beyond the gory details
Now that we have a clear understanding of the underlying principles behind $PATH and $PYTHONPATH, we can now understand what the virtualenv (and additionally, virtualenvwrapper is useful) does for us.
When we create a new virtualenv giving it a directory, what we are saying is that we want to symlink a specific python interpreter (via -p python2.7 flag for the virtualenv command) for example to that virtualenv.
When we source activate that virtualenv we created, we are in fact invoking shell scripts that come with virtualenv to dynamically modify the $PATH. Try running echo $PATH after you have source activated a virtualenv you created. What do you see?
That's right, you will be seeing something like this:-
/Users/calvin/.virtualenvs/myproject/bin:/usr/local/sbin:/usr/local/bin:/usr/bin
And if you type which python, what do you get?
/Users/calvin/.virtualenvs/myproject/bin/python
That's right, the python interpreter we are using is the one that is inside the virtualenv directory and no longer from the /usr/bin directory.
If you run
ls -la /Users/calvin/.virtualenvs/myproject/bin
what do you see?
Ah! A symlink to the specific global python interpreter you specified when you created this virtualenv. If you don't see a symlink, this means that your entire python interpreter was copied over from the globally installed one.
So this is what our virtualenv tool does. It lets us isolate specific projects and choose which python interpreter to use for a specific project.
Once you have source activated a virtualenv, your pip is also the pip that is located in your virtualenv directory. This pip is python path-aware. When you issue pip install commands, python packages now gets installed into your
/Users/calvin/.virtualenvs/myproject/lib/site-packages
python packages directory; and are available ONLY to your project when you source activate that particular project.
What if you install packages with sudo pip?
sudo pip calls the pip tool that comes with your globally installed python interpreter. When you use sudo pip, you are installing your python packages into a global location (which is not jailed within a virtualenv).
I did not give you specific answers to your how-can-I-make-two-projects-use-two-different-python-interpreters question. I explained the principles and now that you know the principles, it is clear what you need to do. Cheers!
:D
you should have to try following steps to make your django work with python-2.7.
As Ubuntu-14 already come with Python-2.7 installed. so no need to install python-2.7.
First of all install python setuptools for python-2.7:
https://pypi.python.org/packages/source/s/setuptools/setuptools-12.0.5.tar.gz
tar -zxvf setuptools-12.0.5.tar.gz
cd setuptools-12.0.5/
sudo python2.7 setup.py install
after install setuptools install pip for python-2.7
wget https://pypi.python.org/packages/source/p/pip/pip-6.0.8.tar.gz
tar -zxvf pip-6.0.8.tar.gz
cd pip-6.0.8/
sudu python2.7 setup.py install
after installing pip now we have to go for install python virtual environment:
sudo pip2.7 install virtualenv
then to folder where you want to create new virtualenv using python 2.7
virtualenv-2.7 "name for new virtualenv for example '/var/virtual/DjangoProject'"
cd /var/virtual/
virtualenv-2.7 DjangoProject
Note just created virtualenv name is "DjangoProject"
Now time to activate new virtualenv
cd DjangoProject
source bib/activate
Now time to clone your project here.
git clone "your git url"
install rest of apps and django here. if you have created simply install by requirement.txt
cd "projectFolder"
pip install -r requirement.txt
after doing all these your new python2.7 django with virtualenv are ready to use. just run django wsgi server for test is every thing working:
python manage.py runserver.
Now you can use this virtualenv and project to setup for web server.
Hope this will help-full to you.
You should use pyenv (and pyenv virtualenvwrapper). With these tools you can have multiple Python versions and switch between them.
Here is how you setup one environment with Python 3.4.2 and one with Python 2.7.8 (and each environment can have its own Python packages)
# install pyenv
git clone https://github.com/yyuu/pyenv.git ~/.pyenv
# setup pyenv and load when shell is loaded
echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bashrc
echo 'export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(pyenv init -)"' >> ~/.bashrc
# install pyenv virtualenvwrapper
git clone https://github.com/yyuu/pyenv-virtualenvwrapper.git ~/.pyenv/plugins/pyenv-virtualenvwrapper
# setup pyenv virtualenvwrapper and load when shell is loaded
echo 'export PYENV_VIRTUALENVWRAPPER_PREFER_PYVENV="true"' >> ~/.bashrc
echo "pyenv virtualenvwrapper" >> ~/.bashrc
Now everything is setup. Restart your shell.
# install python 2.7.8
pyenv install 2.7.8
pyenv rehash
# install python 3.4.2
pyenv install 3.4.2
pyenv rehash
# switch the global python version to 2.7.8
pyenv global 2.7.8
# create a virtual environment using python 2.7.8
mkvirtualenv project278
# -- now you can install you python 2 modules
# leave the virtual environment
deactivate
# switch the global python to 3.4.2
pyenv global 3.4.2
# create a virtual environment using python 3.4.2
mkvirtualenv project342
# -- now you can install you python 2 modules
# leave the virtual environment
deactivate
# switch the global python to the system python.
pyenv global system
# swith to environment project278 and check the python version
workon project278
python --version
# swith to environment project342 and check the python version
workon project342
python --version
VoilĂ ! You now have two environments with different Python versions. Just use the workon (and the deactivate) commands to switch between them.
Make sure you read the documentation of the used packages, so you understand what is going on!

How to install meteor on FreeBSD?

I'm trying to run meteorjs on FreeBSD 9.
I already have nodejs installed from ports.
I also tried:
git clone https://github.com/meteor/meteor.git and then node meteor --help but it does not work.
And I found this "if" into meteor file:
if [ "$UNAME" != "Linux" -a "$UNAME" != "Darwin" ] ; then
echo "Sorry, this OS is not supported."
exit 1
fi
Is there some info on how to install or build meteorjs on FreeBSD?
Thanks!
I've created a custom dev bundle for FreeBSD: https://github.com/yonas/meteor-freebsd
Here are the installation instructions:
Install required packages
sudo pkg install bash ca_root_nss curl expat gettext-runtime git-lite gmake indexinfo libevent2 libffi mongodb node npm pcre perl5 python2 python27 snappy v8
Install Meteor
git clone git://github.com/yonas/meteor-freebsd.git
sudo mv meteor-freebsd /usr/local/share/meteor
sudo ln -s /usr/local/share/meteor/meteor /usr/local/bin/meteor
Create and launch an app
meteor create myapp
cd myapp
meteor
Meteor does not officially support FreeBSD, but it might work. You'll need to generate your own 'dev bundle' (per https://github.com/meteor/meteor#slow-start-for-developers).
First, you'll need to disable the OS specific safety belts in meteor and admin/generate-dev-bundle.sh. You'll also need to get MongoDB binaries from somewhere, as 10gen does not provide pre-built binaries for FreeBSD.
In theory, you should then be able to build a dev bundle with the script. The dev bundle should be the only OS specific portion of meteor, once you have a working dev bundle the rest of the code should run normally.