aji/costapy.ditaajipratama.net
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Updating venv docs

Browse Source
This commit is contained in:
Dita Aji Pratama 2026-01-03 17:14:44 +07:00
parent 0f368e9a49
commit ff81a00ad6
4 changed files with 18 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
_sidebar.md
View File

@ -33,7 +33,5 @@
-->
* Requirement
* git
* python
* pip
* [git](pages/requirement/git.md)
* [venv](pages/requirement/venv.md)

2
pages/getting-starter.md
View File

@ -2,7 +2,7 @@
## Requirement
You need a `git`, `python`, `pip`, and [venv](pages/requirement/venv.md) before using CostaPy.
You need a [git](pages/requirement/git.md), `python`, `pip`, and [venv](pages/requirement/venv.md) before using CostaPy.
Install them using the following commands on your `Debian` or `Ubuntu` system.

3
pages/requirement/git.md Normal file
View File

@ -0,0 +1,3 @@
# git
Work in progress

20
pages/requirement/venv.md
View File

@ -1,15 +1,21 @@
# venv
- Why must `venv`?
## Why must `venv`?
`venv` is a module in Python that provides support for creating lightweight, isolated Python environments, known as virtual environments. Each virtual environment has its own installation directories and can have its own versions of Python packages, independent of the system-wide Python environment.
Modern Debian & Ubuntu follow `PEP 668`. This is why you see errors like `error: externally-managed-environment`. It literally means "This Python environment is managed by the OS. Don’t touch it with pip.".
When deploying a Python application, using a virtual environment ensures that only the required packages (and their specific versions) are bundled. This reduces the risk of deploying unnecessary packages or incompatible versions that could lead to runtime errors.
`venv` is a module in Python that provides support for creating lightweight, isolated Python environments, known as virtual environments. Each virtual environment has its own installation directories and can have its own versions of Python packages, independent of the system-wide Python environment.
Using `venv` is a widely accepted best practice in the Python community. It encourages good habits in dependency management, ensuring that projects are self-contained and reducing the potential for "dependency hell."
When deploying a Python application, using a virtual environment ensures that only the required packages (and their specific versions) are bundled. This reduces the risk of deploying unnecessary packages or incompatible versions that could lead to runtime errors.
When a project is no longer needed, deleting its virtual environment is straightforward and does not affect other projects or the system's Python environment.
Using `venv` is a widely accepted best practice in the Python community. It encourages good habits in dependency management, ensuring that projects are self-contained and reducing the potential for "dependency hell."
- Why I add `venv` on my `gitignore`?
When a project is no longer needed, deleting its virtual environment is straightforward and does not affect other projects or the system's Python environment.
Committing `venv` to Git is gross. Virtual environments can contain thousands of files and their size can be in gigabytes. Committing them to Git can overload and clutter your source code repo with unnecessary files and cause confusion for anyone trying to clone and run the source code on their machine.
## How it works?
When you run `python3 -m venv your_venv_directory_name`, Python creates a directory for “A mini Python install just for this project”. When you activate it with `source .venv/bin/activate`, your shell is told "When I type `python` or `pip`, use the ones inside `.venv`", Nothing else changes. So, when you type `pip install requests`, it installs only inside `.venv`. Then, you can deactivate venv with `deactivate` command.
## Why I add `venv` on my `gitignore`?
Committing `venv` to Git is gross. Virtual environments can contain thousands of files and their size can be in gigabytes. Committing them to Git can overload and clutter your source code repo with unnecessary files and cause confusion for anyone trying to clone and run the source code on their machine.