Virtual Environment + virtualenv

A virtual environment (Sanal Ortam in Turkish) is a self-contained directory that holds a specific Python interpreter installation and its associated libraries and scripts. It allows developers to create isolated environments for Python projects, ensuring that each project can have its own dependencies without interfering with others or the global Python installation.

Why Use Virtual Environments?
1. Dependency Management: Different projects often require different versions of the same library. Without virtual environments, installing `library_A==1.0` for Project X and `library_A==2.0` for Project Y would lead to conflicts or break one of the projects.
2. Clean Global Installation: Keeps the global Python installation tidy, free from project-specific packages. This prevents accidental corruption of the system's Python or base dependencies.
3. Reproducibility: Makes it easy to share projects. Developers can share a `requirements.txt` file, and others can recreate the exact same development environment with all necessary dependencies and their specific versions.
4. Testing: Facilitates testing with different Python versions or library configurations.

What is `virtualenv`?
`virtualenv` is a third-party tool (a Python package) that creates these isolated Python environments. It was one of the earliest and most widely used tools for this purpose before `venv` (a similar tool) was introduced into the Python standard library with Python 3.3. While `venv` is now the recommended tool for Python 3.3+, `virtualenv` remains highly relevant, especially for:
- Projects requiring Python 2.
- Older Python 3 versions where `venv` might not be available or fully featured.
- More advanced configurations or specific use cases not covered by `venv`.
- Situations where you need to create virtual environments for multiple Python versions from a single `virtualenv` installation.

How `virtualenv` Works:
When you create a virtual environment with `virtualenv`, it creates a directory (e.g., `myenv`) containing:
- A copy or symbolic link to a specific Python interpreter.
- Its own `pip` installer.
- Its own `site-packages` directory, where project-specific libraries are installed.

When you 'activate' a virtual environment, your shell's PATH variable is temporarily modified to point to the virtual environment's Python and script directories, making its Python interpreter and installed packages the default for that shell session.

 1. Install virtualenv (if you don't have it already)
pip install virtualenv

 2. Navigate to your project directory (or create one)
mkdir my_python_project
cd my_python_project

 3. Create a virtual environment named 'myenv'
 This will create a 'myenv' directory inside 'my_python_project'
virtualenv myenv

 4. Activate the virtual environment
 On macOS and Linux:
source myenv/bin/activate

 On Windows (Command Prompt):
myenv\Scripts\activate

 On Windows (PowerShell):
myenv\Scripts\Activate.ps1

 You'll notice your shell prompt changes to indicate the active environment
 (myenv) $ 

 5. Install a package within the activated environment
 This package will only be available in 'myenv'
(myenv) pip install requests

 6. Verify the installed package using pip freeze
 It will show 'requests' and its dependencies
(myenv) pip freeze

 7. Deactivate the virtual environment
 The shell prompt will return to normal
(myenv) deactivate

 8. Verify 'requests' is not available globally
 This command will not show 'requests' (unless it was globally installed previously)
pip freeze