<SYSTEM_TASK:>
Given the following text description, write Python code to implement the functionality described below step by step
<END_TASK>
<USER_TASK:>
Description:
 Preliminaries
Assuming either
Linux (Ubuntu)
macOS
though Windows is still doable; the parts about the PATH variables may or may not be relevant.
Part 1
Step1:  The download takes awhile; it's a big distribution!
Once it's downloaded, all you have to provide is an install prefix, i.e. where you want this Python install to live on your computer.
I like to install mine at /opt/conda, but that's a global configuration.
You can just as easily do a local one at /home/&lt;your_username&gt;/conda or /home/&lt;your_username&gt;/python or whatever you'd like!
Step2:  This part will take awhile, depending largely on your internet connection. Go grab some coffee!
There's one more small step to be done, and here's where things might get confusing if you've little or no experience installing things by command line.
You've installed Python locally, and that's super-cool--uninstall is quite literally as easy as trashing the directory you put after the -p flag--but the problem is, your computer doesn't know where it is.
Step3:  This is a great command to test exactly what version of python is being executed. In this case, it's a version I'd installed previous, at /opt/python. That is definitely not the version I just installed. How do I alert my operating system that, when I type a command starting with python, I want it to refer to the local one I just installed?
You have two options
Step4:  As you can see, I already have four Python environments up and running for several different versions of Python.
Creating a new "ad-hoc" environment
This is certainly the easiest way of creating a new environment
Step5:  Ta-daa!
Let's break it down
Step6:  Addendum
Step7:  There you go! Two identical but completely distinct environments.
Exporting environments
You've gone through all this trouble to set up and configure your environment. Over the days/weeks/months, you've installed and removed certain packages. You have the perfect environment.
Now, your friend wants the same environment. We've seen how easy it is to clone existing environments on the same machine, but what about sending the environment schematics elsewhere?
As an example, I maintain a list of Python packages that I use to rebuild my default environment from scratch in the case of catastrophic failure.
In this case, you can export your environments into the super-friendly YAML format
Step8:  This creates a file myenv2.yaml (which you can name whatever you want) from the "myenv2" environment. Here are the contents of the file
Step9:  It's incredibly detailed, down to the exact versions of each package used in the environment. Short of the operating system itself, you can use this to duplicate environments exactly on different computers.
Creating manually-built environments
Then, of course, there's the opposite operation
<ASSISTANT_TASK:>
Python Code:
# Step 1: right-click the "download" link on the left
# Step 2: select "copy link address"
# Step 3: paste the link into the following bash command, after "wget"
!wget https://repo.continuum.io/archive/Anaconda3-4.4.0-Linux-x86_64.sh
Explanation: Preliminaries
Assuming either
Linux (Ubuntu)
macOS
though Windows is still doable; the parts about the PATH variables may or may not be relevant.
Part 1: Installing Anaconda
Anaconda is an incredibly popular Python distribution platform. It's the product of Continuum Analytics, and is effectively the de facto way to interact with the Python ecosystem at this point.
(Translation: Use Anaconda for installing Python. DO NOT USE python.org unless you are super comfortable with micromanaging your Python install and the packages you download)
Installing Anaconda is easy enough: navigate to this link https://www.continuum.io/downloads
The website will auto-detect your operating system and present you with the relevant downloads (but of course you can pick another if you want).
Since I do pretty much everything by command line these days (and Jupyter notebooks provide a direct interface to the command line!), I'll go with the Linux version of the installer (but again, the Windows exe and macOS pkg will provide a GUI installer if you really want it).
End of explanation
!ls # This will show us the files in our current directory
# This is an easy one-liner, but it's absolutely necessary: it makes the file *executable*
!chmod +x Anaconda3-4.4.0-Linux-x86_64.sh
# The "-b" flag means "batch", which means the install won't stop to ask us pesky questions
# The "-p" flag expects a path where Python will be installed. I've provided a local one
!bash Anaconda3-4.4.0-Linux-x86_64.sh -b -p ./conda-install
Explanation: The download takes awhile; it's a big distribution!
Once it's downloaded, all you have to provide is an install prefix, i.e. where you want this Python install to live on your computer.
I like to install mine at /opt/conda, but that's a global configuration.
You can just as easily do a local one at /home/&lt;your_username&gt;/conda or /home/&lt;your_username&gt;/python or whatever you'd like!
End of explanation
!which python
Explanation: This part will take awhile, depending largely on your internet connection. Go grab some coffee!
There's one more small step to be done, and here's where things might get confusing if you've little or no experience installing things by command line.
You've installed Python locally, and that's super-cool--uninstall is quite literally as easy as trashing the directory you put after the -p flag--but the problem is, your computer doesn't know where it is.
End of explanation
!conda env list
Explanation: This is a great command to test exactly what version of python is being executed. In this case, it's a version I'd installed previous, at /opt/python. That is definitely not the version I just installed. How do I alert my operating system that, when I type a command starting with python, I want it to refer to the local one I just installed?
You have two options: both involve editing the PATH environment variable that is more or less singularly responsible for telling your computer where everything is (if you've ever accidentally nuked this variable, you know how important it is). The difference is how your edits persist.
Option 1: Edit your .bashrc (*nix) or .profile (macOS)
This makes the changes stick, even after you close down your command prompt. Even after you reboot!
Open up the correct file (they're both found in your home directory).
At the end of the file, put the following line:
export PATH=/home/&lt;your_username&gt;/conda-install/bin:$PATH
Basically, the FULL path of whatever directory you provided to the Anaconda installer, with /bin tacked on the end.
Also, don't forget the colon and the $PATH suffix! Doing so will achieve said nuking of the variable!
Option 2: DO IT LIVE
This is essentially: changing the variable for the duration of time you have your command prompt window open. Once you close it down, your computer reverts to whatever configuration it was before. That can be achieved simply by running the above command right in your command prompt window:
export PATH=/home/&lt;your_username&gt;/conda-install/bin:$PATH
I'll do that one here, using the Terminal interface provided by Jupyter notebooks:
Once you type exit on that command prompt, those changes will go away and the PATH variable will revert to whatever it was before, obviously devoid of the changes you made with respect to the local Python install. So if you want the changes to stick, go with Option 1.
Option 3: It's done for you
If you use the exe or pkg installers provided by the Windows or macOS versions respectively, they do this exact thing under the hood!
Part 2: Conda Environments
One of the most powerful aspects of Anaconda is the concept of the environment.
Have you heard of virtualenv? It's a Python package that allows to create "virtual environments" that are completely disconnected from each other. Reasons you might want to have parallel Python environments existing completely separately from one another:
Testing version compatibility of a software package you're developing
Using a third-party package that is only compatible with certain versions of other packages
Slowly upgrading aspects of an environment while wanting to maintain a working, original "production" environment
... etc
The conda tool, first and foremost, is an environment manager. In fact, when you installed Anaconda, it created an initial "default" environment: using this blueprint as a jumping-off point, you could construct lots of parallel environments using different versions of Python, or the packages, or just different package combinations.
Biggest example: Python 2 versus Python 3.
End of explanation
!conda create -n myenv -y python=2.7 scikit-learn numpy scipy matplotlib
Explanation: As you can see, I already have four Python environments up and running for several different versions of Python.
Creating a new "ad-hoc" environment
This is certainly the easiest way of creating a new environment: just give conda a name and a list of core packages, and you're good to go!
End of explanation
!conda env list
Explanation: Ta-daa!
Let's break it down:
conda create
This is the part of the command that specifies that we want a new environment, separate from the default (or "root").
-n myenv
This part provides the name of the environment. It can be pretty much anything other than "root", aside from any other environments you've named. Try to make the name descriptive of its purpose! (HINT: perhaps name your environments by the project you're working on?...)
python=2.7 scikit-learn numpy scipy matplotlib
This is the list of packages I want my new environment to come with by default: Python (version 2.7), scikit-learn, NumPy, SciPy, and Matplotlib.
After that, conda goes to work! It even provides the instructions at the end for switching into and out of the environment:
source activate myenv
drops you into the environment, and once inside it,
source deactivate
drops you out and back into the default, or root, environment.
End of explanation
!conda create -n myenv2 --clone myenv
!conda env list
Explanation: Addendum: Cloning an existing environment
If you love an environment and have it set up perfectly and want to introduce an unstable element, you can also clone that environment into a new one.
It works the same as before, but in lieu of a package list (which you can still provide!), the main argument is the --clone option:
End of explanation
!conda env export -n myenv2 -f myenv2.yaml
Explanation: There you go! Two identical but completely distinct environments.
Exporting environments
You've gone through all this trouble to set up and configure your environment. Over the days/weeks/months, you've installed and removed certain packages. You have the perfect environment.
Now, your friend wants the same environment. We've seen how easy it is to clone existing environments on the same machine, but what about sending the environment schematics elsewhere?
As an example, I maintain a list of Python packages that I use to rebuild my default environment from scratch in the case of catastrophic failure.
In this case, you can export your environments into the super-friendly YAML format:
End of explanation
# %load myenv2.yaml
name: myenv2
channels:
- menpo
- conda-forge
- defaults
dependencies:
- backports_abc=0.5=py27_0
- blas=1.1=openblas
- ca-certificates=2017.7.27.1=0
- certifi=2017.7.27.1=py27_0
- cycler=0.10.0=py27_0
- dbus=1.10.10=3
- expat=2.2.1=0
- fontconfig=2.12.1=4
- freetype=2.7=1
- functools32=3.2.3.2=py27_1
- gettext=0.19.7=1
- glib=2.51.4=0
- gst-plugins-base=1.8.0=0
- gstreamer=1.8.0=2
- icu=58.1=1
- jpeg=9b=0
- libffi=3.2.1=3
- libiconv=1.14=4
- libpng=1.6.28=0
- libxcb=1.12=1
- libxml2=2.9.4=4
- matplotlib=2.0.2=py27_2
- ncurses=5.9=10
- numpy=1.13.1=py27_blas_openblas_200
- openblas=0.2.19=2
- openssl=1.0.2l=0
- pcre=8.39=0
- pip=9.0.1=py27_0
- pyparsing=2.2.0=py27_0
- pyqt=5.6.0=py27_4
- python=2.7.13=1
- python-dateutil=2.6.1=py27_0
- pytz=2017.2=py27_0
- qt=5.6.2=3
- readline=6.2=0
- scikit-learn=0.19.0=py27_blas_openblas_201
- scipy=0.19.1=py27_blas_openblas_202
- setuptools=36.2.2=py27_0
- singledispatch=3.4.0.3=py27_0
- sip=4.18=py27_1
- six=1.10.0=py27_1
- sqlite=3.13.0=1
- ssl_match_hostname=3.5.0.1=py27_1
- subprocess32=3.2.7=py27_0
- tk=8.5.19=2
- tornado=4.5.1=py27_0
- wheel=0.29.0=py27_0
- xorg-libxau=1.0.8=3
- xorg-libxdmcp=1.1.2=3
- xz=5.2.2=0
- zlib=1.2.11=0
- libgfortran=3.0.0=1
- pip:
  - backports-abc==0.5
  - backports.ssl-match-hostname==3.5.0.1
prefix: /opt/python/envs/myenv2
Explanation: This creates a file myenv2.yaml (which you can name whatever you want) from the "myenv2" environment. Here are the contents of the file:
End of explanation
!conda env create -n myenv3 -f myenv2.yaml
!conda env list
Explanation: It's incredibly detailed, down to the exact versions of each package used in the environment. Short of the operating system itself, you can use this to duplicate environments exactly on different computers.
Creating manually-built environments
Then, of course, there's the opposite operation: creating an environment from a YAML file.
NOTE: You'll notice there's a name field in the YAML file. Since we're performing both the export and import on the same machine, there could be a conflict in the name of the environment. Normally, this wouldn't be the case, but here we'll have to fix that one of two ways.
1: Just change the name of the environment in the YAML file to something else.
2: Use the -n flag to specify a name when you create the environment from the file.
End of explanation
<END_TASK>