VIRTUALENV(1) virtualenv VIRTUALENV(1)

virtualenv - ابزاری برای ایجاد محیط‌های ایزوله پایتون [تصویر: آخرین نسخه در PyPI] [تصویر]
https://pypi.org/project/virtualenv/#history[تصویر: پیاده‌سازی در PyPI] [تصویر] [تصویر: نسخه پایتون در PyPI] [تصویر] [تصویر: وضعیت مستندات] [تصویر]
https://virtualenv.pypa.io[تصویر: دیسکورد] [تصویر]
https://discord.gg/pypa[تصویر: دریافت‌های PyPI] [تصویر]
https://pypistats.org/packages/virtualenv[تصویر: پروانه PyPI] [تصویر]
https://opensource.org/licenses/MIT[تصویر: مسائل باز] [تصویر]
https://github.com/pypa/virtualenv/issues[تصویر: درخواست‌های ادغام باز] [تصویر]
https://github.com/pypa/virtualenv/pulls[تصویر: محبوبیت بسته] [تصویر]
https://pypistats.org/packages/virtualenv

virtualenv ابزاری برای ایجاد محیط‌های ایزوله پایتون است. از نسخه ۳.۳ پایتون، زیرمجموعه‌ای از آن در قالب ماژول venv در کتابخانه استاندارد ادغام شده است. برای بررسی مقایسه virtualenv با ماژول venv در کتابخانه استاندارد، به بخش توضیحات (Explanation) <> مراجعه کنید.

Tutorials (آموزش‌ها) - یادگیری با تمرین عملی

•
شروع به کار (Getting started) <> — ایجاد اولین محیط مجازی و یادگیری گردش کار پایه

How-to guides (راهنماهای کاربردی) - حل مشکلات مشخص

  • نصب virtualenv <> — نصب virtualenv روی سیستم شما
  • استفاده از virtualenv <> — انتخاب نسخه‌های پایتون، فعال‌سازی محیط‌ها، پیکربندی مقادیر پیش‌فرض و استفاده از کدهای پایتون

Reference (مرجع) - اطلاعات فنی

  • سازگاری (Compatibility) <> — نسخه‌های پایتون و سیستم‌عامل‌های پشتیبانی‌شده
  • خط فرمان (Command line) <> — گزینه‌ها و پرچم‌های خط فرمان
  • پایتون (Python) <> — مرجع رابط برنامه‌نویسی (API) پایتون

Explanation (توضیحات) - درک مفاهیم

•
توضیحات (Explanation) <> — نحوه کارکرد درونی virtualenv و دلیل وجود آن

Extensions (افزونه‌ها)

•
پلاگین‌ها (Plugins) <> — گسترش virtualenv با creators، seeders و activators سفارشی

ابزارهای متعددی بر پایه virtualenv ساخته شده‌اند تا جریان‌های کاری سطح بالاتری را ارائه دهند:

درباره virtualenv از این منابع جامعه کاربری بیشتر بیاموزید:

این آموزش مبانی virtualenv را از طریق تمرین عملی به شما می‌آموزد. شما نخستین محیط مجازی خود را ایجاد خواهید کرد، بسته‌ها را نصب می‌کنید و با نحوه مدیریت وابستگی‌های پروژه آشنا می‌شوید.

پیش از آغاز این آموزش، شما به موارد زیر نیاز دارید:

  • نصب بودن پایتون نسخه 3.9 یا جدیدتر روی سیستم شما. اگر از یک ابزار مدیریت نسخه مانند pyenv https://github.com/pyenv/pyenv، mise https://mise.jdx.dev یا asdf https://asdf-vm.com استفاده می‌کنید، virtualenv به‌طور خودکار نسخه پایتون مدیریت‌شده توسط آن‌ها را شناسایی می‌کند.
  • نصب بودن virtualenv (بخش Install virtualenv <> را ببینید).

بیایید یک محیط مجازی به نام myproject ایجاد کنیم:

$ virtualenv myproject
created virtual environment CPython3.13.2.final.0-64 in 200ms
  creator CPython3Posix(dest=/home/user/myproject, clear=False, no_vcs_ignore=False, global=False)
  seeder FromAppData(download=False, pip=bundle, setuptools=bundle, via=copy, app_data_dir=/home/user/.cache/virtualenv)
  activators BashActivator,CShellActivator,FishActivator,NushellActivator,PowerShellActivator,PythonActivator

این کار یک دایرکتوری جدید به نام myproject ایجاد می‌کند که شامل یک محیط پایتون کامل و ایزوله‌شده به همراه نسخه اختصاصی پایتون، pip و سایر ابزارها است.

مفسر به چندین نام پاسخ می‌دهد، بنابراین اسکریپتی که انتظار هر یک از آن‌ها را داشته باشد در داخل محیط به کار خود ادامه می‌دهد:

$ ls myproject/bin/python*
myproject/bin/python  myproject/bin/python3  myproject/bin/python3.13

بخش ساختار محیط (Environment layout) <> فهرست کامل را ارائه می‌دهد که این موارد در ویندوز متفاوت است.

برای استفاده از محیط مجازی خود، می‌توانید آن را فعال کنید. دستور فعال‌سازی بسته به بستر و پلتفرم متفاوت است: [Linux/macOS]

$ source myproject/bin/activate
[Windows (PowerShell)]
PS> .\myproject\Scripts\Activate.ps1
[Windows (CMD)]
C:\> .\myproject\Scripts\activate.bat

پس از فعال‌سازی، اعلان خط فرمان (prompt) شما برای نمایش محیط فعال تغییر می‌کند:

(myproject) $

می‌توانید بررسی کنید که پایتون اکنون از داخل محیط مجازی اجرا می‌شود: [Linux/macOS]

(myproject) $ which python
/home/user/myproject/bin/python
[Windows (PowerShell)]
(myproject) PS> where.exe python
C:\Users\user\myproject\Scripts\python.exe
[Windows (CMD)]
(myproject) C:\> where.exe python
C:\Users\user\myproject\Scripts\python.exe

با فعال بودن محیط، یک بسته را با استفاده از pip نصب کنید:

(myproject) $ pip install requests
Collecting requests
  Using cached requests-2.32.3-py3-none-any.whl (64 kB)
Installing collected packages: requests
Successfully installed requests-2.32.3

بررسی کنید که بسته تنها درون محیط مجازی شما نصب شده باشد:

(myproject) $ python -c "import requests; print(requests.__file__)"
/home/user/myproject/lib/python3.13/site-packages/requests/__init__.py

این مسیر نشان می‌دهد که requests در محیط مجازی نصب شده است، نه در Python سیستم شما.

هنگامی که کارتان در محیط مجازی به پایان رسید، آن را غیرفعال کنید:

(myproject) $ deactivate
$

اعلان خط فرمان به حالت عادی بازمی‌گردد و دستورهای Python مجدداً از Python سیستم شما استفاده می‌کنند.

فعال‌سازی تنها برای راحتی است و الزامی نیست. شما می‌توانید هر فایل اجرایی را مستقیماً با استفاده از مسیر کامل آن از محیط مجازی اجرا کنید: [Linux/macOS]

$ myproject/bin/python -c "import sys; print(sys.prefix)"
/home/user/myproject
$ myproject/bin/pip install httpx
[Windows (PowerShell)]
PS> .\myproject\Scripts\python.exe -c "import sys; print(sys.prefix)"
C:\Users\user\myproject
PS> .\myproject\Scripts\pip.exe install httpx
[Windows (CMD)]
C:\> .\myproject\Scripts\python.exe -c "import sys; print(sys.prefix)"
C:\Users\user\myproject
C:\> .\myproject\Scripts\pip.exe install httpx

این روش به‌ویژه در اسکریپت‌ها، خطوط لوله CI و خودکارسازی که در آن‌ها نیازی به دستکاری محیط شل نیست، بسیار کاربردی است..SS راه‌اندازی یک پروژه واقعی

اکنون بیایید آنچه آموخته‌اید را در گردش کار یک پروژه واقعی به کار بگیریم:

$ mkdir myapp && cd myapp
$ virtualenv venv
$ source venv/bin/activate  # or use the appropriate command for your platform
(venv) $ pip install flask requests
(venv) $ pip freeze > requirements.txt

فایل requirements.txt اکنون شامل وابستگی‌های پروژه شما است:

blinker==1.9.0
certifi==2025.1.31
charset-normalizer==3.4.1
click==8.1.8
flask==3.1.0
idna==3.10
itsdangerous==2.2.0
Jinja2==3.1.5
MarkupSafe==3.0.2
requests==2.32.3
urllib3==2.3.0
werkzeug==3.1.3

این فایل به شما امکان می‌دهد بعداً دقیقاً همان محیط را بازسازی کنید. بیایید این را آزمایش کنیم:

(venv) $ deactivate
$ rm -rf venv
$ virtualenv venv
$ source venv/bin/activate
(venv) $ pip install -r requirements.txt

تمام بسته‌ها دقیقاً مانند قبل دوباره نصب می‌شوند. گردش کار کامل در ادامه آمده است: [graph]

در این آموزش، شما یاد گرفتید چگونه:

  • یک محیط مجازی با virtualenv ایجاد کنید.
  • محیط‌های مجازی را در پلتفرم‌های مختلف فعال و غیرفعال کنید.
  • بسته‌ها را به‌صورت ایزوله‌شده از پایتون سیستم خود نصب کنید.
  • وابستگی‌های پروژه را با pip freeze ذخیره کنید.
  • محیط‌ها را با استفاده از requirements.txt بازتولید کنید.

اکنون که با مبانی آشنا شدید، این موضوعات را کاوش کنید:

  • بخش Use virtualenv <> برای انتخاب نگارش‌های خاص پایتون، پیکربندی پیش‌فرض‌ها و الگوهای استفاده پیشرفته.
  • بخش Explanation <> برای درک نحوه کارکرد درونی virtualenv و مقایسه آن با venv.
  • بخش Command line <> برای تمام گزینه‌ها و پرچم‌های موجود در خط فرمان.

ابزار virtualenv یک ابزار خط فرمانی است، بنابراین باید به جای پایتون سیستم شما، در یک محیط ایزوله نصب شود. روشی را که با ساختار شما سازگار است انتخاب کنید:

  • ابزار uv https://docs.astral.sh/uv -- مدیر بسته سریع و مدرن پایتون. اگر از قبل uv را دارید یا می‌خواهید تازه شروع کنید از این گزینه استفاده کنید.
  • ابزار pipx https://pipx.pypa.io/stable -- ابزارهای خط فرمان پایتون را در محیط‌های ایزوله نصب می‌کند. اگر از قبل pipx را راه‌اندازی کرده‌اید از این گزینه استفاده کنید.
  • ابزار pip https://pip.pypa.io/stable -- نصاب استاندارد بسته‌های پایتون. از گزینه --user استفاده کنید تا از تغییر بسته‌های سیستم جلوگیری شود. ممکن است در توزیع‌هایی با محیط‌های پایتون مدیریت‌شده از خارج کار نکند.
  • بسته zipapp https://docs.python.org/3/library/zipapp.html -- یک فایل اجرایی مستقل بدون نیاز به نصب. از این در CI یا محیط‌هایی که نمی‌توانید بسته‌ها را نصب کنید استفاده کنید.
[graph][uv] نصب virtualenv به عنوان یک ابزار uv https://docs.astral.sh/uv/concepts/tools:
$ uv tool install virtualenv

نصب نگارش توسعه:

$ uv tool install git+https://github.com/pypa/virtualenv.git@main
[pipx] نصب virtualenv با استفاده از pipx https://pipx.pypa.io/stable:
$ pipx install virtualenv

نصب نگارش توسعه:

$ pipx install git+https://github.com/pypa/virtualenv.git@main
[pip] نصب virtualenv با استفاده از pip https://pip.pypa.io/stable:
$ python -m pip install --user virtualenv

نصب نگارش توسعه:

$ python -m pip install git+https://github.com/pypa/virtualenv.git@main

هشدار:

برخی از توزیع‌های لینوکس از محیط‌های پایتون مدیریت‌شده توسط سیستم استفاده می‌کنند. اگر با خطاهایی درباره محیط‌های مدیریت‌شده از خارج (externally-managed) روبرو شدید، به جای آن از uv tool یا pipx استفاده کنید.
[zipapp] فایل zipapp را بارگیری کرده و آن را مستقیماً اجرا کنید:
$ python virtualenv.pyz --help

آخرین نگارش را از https://bootstrap.pypa.io/virtualenv.pyz یا یک نگارش خاص را از https://bootstrap.pypa.io/virtualenv/x.y/virtualenv.pyz بارگیری کنید..SS بررسی نصب

بررسی نسخه نصب‌شده:

$ virtualenv --version

برای نسخه‌های پشتیبانی‌شده Python بخش Compatibility <> را ببینید.

به‌طور پیش‌فرض، virtualenv از همان نسخه Python که تحت آن اجرا می‌شود استفاده می‌کند. این مقدار را با --python یا -p تغییر دهید.

تعیین یک نسخه Python با نام یا شماره نسخه:

$ virtualenv -p python3.14 venv
$ virtualenv -p 3.10 venv
$ virtualenv -p pypy3 venv
$ virtualenv -p rustpython venv

از مشخص‌کننده‌های نسخه PEP 440 https://peps.python.org/pep-0440/#version-specifiers برای مطابقت دادن نسخه‌های Python استفاده کنید:

$ virtualenv --python ">=3.12" venv
$ virtualenv --python "~=3.11.0" venv
$ virtualenv --python "cpython>=3.10" venv
  • >=3.12 -- هر نسخه Python 3.12 یا بالاتر.
  • ~=3.11.0 -- انتشار سازگار، معادل >=3.11.0, <3.12.0 (هر وصله 3.11.x).
  • cpython>=3.10 -- محدود به پیاده‌سازی CPython، نسخه 3.10 یا بالاتر.

ایجاد یک محیط با Python دارای قابلیت free-threading https://docs.python.org/3/howto/free-threading-python.html:

$ virtualenv -p 3.13t venv

روی دستگاه‌هایی که از چندین معماری پشتیبانی می‌کنند — مانند Apple Silicon (ترکیب arm64 + x86_64 از طریق Rosetta) یا Windows on ARM — می‌توانید با الحاق آن به انتهای رشته مشخصات، معماری پردازنده مشخصی را درخواست کنید:

$ virtualenv -p cpython3.12-64-arm64 venv
$ virtualenv -p 3.11-64-x86_64 venv

نام‌های مستعار چندسکویی به‌طور خودکار عادی‌سازی می‌شوند، بنابراین با amd64 و x86_64 معادل یکدیگر رفتار می‌شود، همان‌طور که با aarch64 و arm64. در صورت حذف، هر معماری مطابقت داده می‌شود (حفظ رفتار موجود).

تعیین مسیر کامل به یک مفسر Python:

$ virtualenv -p /usr/bin/python3.9 venv

از --try-first-with برای ارائه یک راهنمایی درباره این‌که کدام پایتون ابتدا بررسی شود استفاده کنید. بر خلاف --python، این یک پیشنهاد است تا یک قانون قطعی. مفسر موجود در این مسیر ابتدا بررسی می‌شود، اما تنها در صورتی استفاده خواهد شد که با قید --python مطابقت داشته باشد.

$ virtualenv --python ">=3.10" --try-first-with /usr/bin/python3.9 venv

در این مثال، ابتدا /usr/bin/python3.9 بررسی می‌شود اما به دلیل برآورده نکردن شرط >=3.10 رد می‌شود.

ابزار virtualenv به‌طور خودکار شیم‌های (shims) مربوط به pyenv https://github.com/pyenv/pyenv، mise https://mise.jdx.dev و asdf https://asdf-vm.com را به باینری واقعی پایتون ارجاع می‌دهد. نسخه فعال پایتون را با استفاده از هر یک از سازوکارهای استاندارد تنظیم کنید تا virtualenv آن را شناسایی کند:

$ pyenv local 3.12.0
$ virtualenv venv  # uses pyenv's 3.12.0, not the system Python
$ PYENV_VERSION=3.11.0 virtualenv venv  # uses 3.11.0

این قابلیت با mise و asdf نیز کار می‌کند:

$ mise use python@3.12
$ virtualenv venv

هیچ پیکربندی اضافی نیاز نیست. برای جزئیات در مورد نحوه عملکرد تفکیک شیم (shim resolution)، بخش Explanation <> را ببینید.

برای تغییر متغیرهای محیطی و PATH پوسته خود، محیط مجازی را فعال کنید. [Bash/Zsh]

$ source venv/bin/activate
[Fish]
$ source venv/bin/activate.fish
[PowerShell]
PS> .\venv\Scripts\Activate.ps1

نکته:

اگر با خطای execution policy مواجه شدید، دستور Set-ExecutionPolicy RemoteSigned را برای مجاز کردن اسکریپت‌های محلی اجرا کنید.
[CMD]
> .\venv\Scripts\activate.bat
[Nushell]
$ overlay use venv/bin/activate.nu
[Xonsh]
@ source venv/bin/activate.xsh

خروج از محیط مجازی:

$ deactivate

استفاده از محیط بدون نیاز به فعال‌سازی آن، با فراخوانی مستقیم فایل‌های اجرایی از طریق مسیر کامل آن‌ها:

$ venv/bin/python script.py
$ venv/bin/pip install package

python، python3 و نام‌های دارای شماره نسخه، همگی به یک مفسر یکسان اشاره می‌کنند؛ همچنین در ویندوز، فایل‌های اجرایی با پسوند .exe در پوشهٔ venv\Scripts قرار دارند. هر زمان که به فرایندی بدون پنجرهٔ کنسول نیاز داشتید، از pythonw.exe در آن مسیر استفاده کنید. طرح‌بندی محیط <> تمام نام‌ها را فهرست می‌کند.

تنظیم یک پیشوند سفارشی برای پرامپت:

$ virtualenv --prompt myproject venv

غیرفعال‌سازی تغییر پرامپت خط فرمان با مقداردهی متغیر محیطی VIRTUAL_ENV_DISABLE_PROMPT.

دسترسی به رشتهٔ پرامپت از طریق متغیر محیطی VIRTUAL_ENV_PROMPT.

فعال‌سازی محیط از درون یک فرایند در حال اجرای پایتون با استفاده از activate_this.py. این اسکریپت sys.path و متغیرهای محیطی را در فرایند جاری تغییر می‌دهد، به‌گونه‌ای که درون‌ریزی‌های (import) بعدی از محیط مجازی بارگذاری شوند.

import runpy
runpy.run_path("venv/bin/activate_this.py")

یک کاربرد رایج، برنامه‌های تحت وبی هستند که توسط یک وب‌سرور سراسری WSGI در سیستم (مانند mod_wsgi یا uWSGI) میزبانی می‌شوند و نیاز دارند بسته‌ها را از یک محیط مجازی بارگذاری کنند:

import runpy
from pathlib import Path
runpy.run_path(str(Path("/var/www/myapp/venv/bin/activate_this.py")))
from myapp import create_app  # noqa: E402
application = create_app()

استفاده از یک فایل پیکربندی برای تعیین گزینه‌های پیش‌فرض virtualenv.

فایل پیکربندی virtualenv.ini نام دارد و در دایرکتوری app config مربوط به platformdirs قرار گرفته است. دستور virtualenv --help را اجرا کنید تا مسیر دقیق آن را در سیستم خود بیابید.

تغییر مسیر فایل پیکربندی با استفاده از متغیر محیطی VIRTUALENV_CONFIG_FILE..SS قالب پیکربندی

کلیدهای پیکربندی را می‌توان با حذف - از ابتدای گزینه‌های خط فرمان و جایگزین کردن -های باقی‌مانده با _ به دست آورد:

[virtualenv]
python = /opt/python-3.14/bin/python

مقادیر چندگانه را در خطوط جداگانه مشخص کنید:

[virtualenv]
extra_search_dir =
    /path/to/dists
    /path/to/other/dists

گزینه‌ها را با استفاده از متغیرهای محیطی دارای پیشوند VIRTUALENV_ و نام‌های کلید با حروف بزرگ تنظیم کنید:

$ export VIRTUALENV_PYTHON=/opt/python-3.14/bin/python

برای گزینه‌های چندمقداری، مقادیر را با ویرگول یا خطوط جدید از هم جدا کنید.

متغیر محیطی VIRTUALENV_OVERRIDE_APP_DATA را برای تغییر مکان پیش‌فرض دایرکتوری حافظه موقت (cache) app-data تنظیم کنید.

به‌روزرسانی دوره‌ای با واکشی https://pypi.org/pypi/<distribution>/json بسته‌های اولیهٔ (seed wheels) جدیدتر را بررسی می‌کند. این درخواست با اعتبارسنجی کامل TLS انجام می‌شود و در صورت شکست درخواست تأییدشده، virtualenv اکنون به‌جای تنزل دادن امنیت اتصال، از به‌روزرسانی صرف‌نظر می‌کند. مقدار VIRTUALENV_PERIODIC_UPDATE_INSECURE=1 را تنظیم کنید تا رفتار پیشین بازیابی شده و درخواست مجدداً با یک بافت (context) تأییدنشدهٔ SSL تلاش شود. این یک راه گریز برای میزبان‌هایی با مخازن اعتماد (trust stores) معیوب است؛ آن را روی میزبان‌هایی که تحت کنترل شما نیستند تنظیم نکنید.

گزینه‌ها به این ترتیب حل‌وفصل می‌شوند (از بالاترین به پایین‌ترین اولویت): [graph]

فایل‌های wheel تعبیه‌شده را به آخرین نسخه‌ها به‌روزرسانی کنید:

$ virtualenv --upgrade-embed-wheels

از فایل‌های wheel سفارشی از یک دایرکتوری محلی استفاده کنید:

$ virtualenv --extra-search-dir /path/to/wheels venv

آخرین نسخه‌های بسته‌های اولیه (seed packages) را از PyPI دریافت کنید:

$ virtualenv --download venv

غیرفعال‌سازی به‌روزرسانی‌های خودکار دوره‌ای بسته‌های اولیه (seed packages):

$ virtualenv --no-periodic-update venv

ماژول virtualenv.seed.wheels.embed را وصله (patch) کرده و PERIODIC_UPDATE_ON_BY_DEFAULT را روی False تنظیم کنید تا به‌روزرسانی‌های دوره‌ای به‌صورت پیش‌فرض غیرفعال شوند. برای جزئیات پیاده‌سازی، Explanation <> را ببینید.

فراخوانی virtualenv از طریق کد Python با استفاده از تابع cli_run:

from virtualenv import cli_run
cli_run(["venv"])

ارسال گزینه‌ها به‌عنوان عناصر لیست:

cli_run(["-p", "python3.14", "--without-pip", "myenv"])

استفاده از شیء session بازگردانده‌شده برای دسترسی به جزئیات محیط:

result = cli_run(["venv"])
print(result.creator.dest)  # path to created environment
print(result.creator.exe)  # path to python executable

استفاده از session_via_cli برای توصیف محیط بدون ایجاد آن:

from virtualenv import session_via_cli
session = session_via_cli(["venv"])
# inspect session.creator, session.seeder, session.activators

برای مستندات کامل API، بخش Python <> را ببینید.

virtualenv با پیاده‌سازی‌های مفسر Python زیر کار می‌کند. فقط آخرین نسخهٔ وصله (patch) از هر نسخهٔ فرعی (minor) به‌طور کامل پشتیبانی می‌شود؛ نسخه‌های وصلهٔ قبلی بر مبنای بهترین تلاش (best effort) عمل می‌کنند.

3.15 >= python_version >= 3.9

3.11 >= python_version >= 3.9

24.1 و جدیدتر (فقط Linux و macOS).

پشتیبانی آزمایشی (Linux، macOS و Windows). سامانهٔ RustPython https://github.com/RustPython/RustPython نگارش Python 3.14 را پیاده‌سازی می‌کند..SS سیاست پشتیبانی (Support policy)

  • نسخه‌های جدید نزدیک به تاریخ انتشارشان، معمولاً در طول فاز بتا اضافه می‌شوند.
  • پشتیبانی از نسخه‌های قدیمی ۱۸ ماه پس از پایان عمر (EOL) در CPython https://devguide.python.org/versions متوقف می‌شود، که به کاربران زمان کافی برای مهاجرت می‌دهد.

تغییرات عمده در پشتیبانی از نسخه‌ها:

  • 21.5.0 (2026-06-13): پشتیبانی از اجرا تحت Python 3.8 و پیش از آن و همچنین ساخت محیط برای آن‌ها متوقف شد.
  • 20.27.0 (2024-10-17): پشتیبانی از اجرا تحت Python 3.7 و پیش از آن متوقف شد.
  • 20.22.0 (2023-04-19): پشتیبانی از ساخت محیط برای Python 3.6 و پیش از آن متوقف شد.
  • 20.18.0 (2023-02-06): پشتیبانی از اجرا تحت Python 3.6 و پیش از آن متوقف شد.

CPython در قالب‌های گوناگونی عرضه می‌شود و هر سیستم‌عامل آن را مجدداً بسته‌بندی کرده و معمولاً سفارشی‌سازی‌هایی روی آن اعمال می‌کند. سکوهای فهرست‌شده در زیر آزمایش شده‌اند. سکوهای فهرست‌نشده ممکن است کار کنند اما رسماً پشتیبانی نمی‌شوند. در صورت مواجهه با مشکل در سکوهای فهرست‌نشده، لطفاً یک درخواست قابلیت (feature request) باز کنید.

این توزیع‌های Python بر روی Linux، macOS و Windows کار می‌کنند:

  • نسخه‌های Python نصب‌شده از طریق Homebrew https://docs.brew.sh/Homebrew-and-Python (کار می‌کند، اما توصیه نمی‌شود https://justinmayer.com/posts/homebrew-python-is-not-for-you -- زیرا Homebrew ممکن است نسخه‌های Python را بدون هشدار ارتقا داده یا حذف کند و محیط‌های مجازی موجود را از کار بیندازد)
  • نسخهٔ Python 3 موجود در XCode (ساخت‌های چارچوب Python در /Library/Frameworks/Python3.framework/)

نکته:

ساخت‌های مبتنی بر چارچوب (Framework) از محیط‌های مجازی مبتنی بر کپی پشتیبانی نمی‌کنند. به‌جای آن از روش‌های ساخت با پیوند نمادین (symlink) یا پیوند سخت (hardlink) استفاده کنید.

•
نسخهٔ Python 3.9 و جدیدتر از Windows Store https://apps.microsoft.com/search?query=python

ابزار virtualenv در درجهٔ اول یک برنامهٔ خط فرمانی است. تمام گزینه‌ها پیش‌فرض‌های منطقی دارند و تنها یک آرگومان اجباری وجود دارد: نام یا مسیر محیط مجازی برای ساخت.

برای چگونگی انتخاب نسخه‌های Python، پیکربندی پیش‌فرض‌ها و استفاده از متغیرهای محیطی، Use virtualenv <> را ببینید.

virtualenv [OPTIONS]

آرگومان‌های نام‌دار
--version '==SUPPRESS==' نمایش نسخهٔ بستهٔ virtualenv و مکان آن، سپس خروج
--with-traceback False در صورت بروز خطا، ردگیری پشته (stacktrace) داخلی virtualenv نیز نمایش داده شود
--read-only-app-data False استفاده از پوشهٔ داده‌های برنامه در حالت فقط‌خواندنی (عملیات‌های نوشتن با خطا مواجه خواهند شد)
--app-data پوشهٔ داده‌های برنامه مختص به سکو یک پوشهٔ داده که توسط virtualenv به عنوان حافظهٔ نهان (cache) استفاده می‌شود
--reset-app-data False شروع با پوشهٔ داده‌های برنامه به صورت خالی
--upgrade-embed-wheels False راه‌اندازی به‌روزرسانی دستی چرخ‌های (wheels) تعبیه‌شده
میزان جزئیات (verbosity) ⇒ verbosity = verbose - quiet، پیش‌فرض INFO، نگاشت => CRITICAL=0, ERROR=1, WARNING=2, INFO=3, DEBUG=4, NOTSET=5
-v, --verbose 2 افزایش میزان جزئیات خروجی
-q, --quiet 0 کاهش میزان جزئیات خروجی
"شناسایی (discovery)"
box center;
l|l|l.
core ⇒ گزینه‌های مشترک میان تمام سازوکارهای شناسایی (discovery)
--discovery 'builtin' روش شناسایی مفسر؛ گزینه‌های موجود: builtin
-p, --python فایل اجرایی پایتونی که virtualenv در آن نصب شده است مفسری که محیط باید بر پایه آن ایجاد شود (مسیر/شناسه/مشخصه‌نگارش) - به‌طور پیش‌فرض از مفسری که ابزار در آن نصب شده استفاده می‌شود - اولین مورد یافت‌شده اعمال می‌شود. مشخصه‌های نگارش (مانند >=3.12،‏ ~=3.11.0،‏ ==3.10) نیز پشتیبانی می‌شوند
--try-first-with [] پیش از آغاز شناسایی، ابتدا این مفسرها بررسی شوند

core ⇒ گزینه‌های مشترک میان تمام سازنده‌ها (creator)
--creator builtin در صورت وجود، وگرنه venv ایجاد محیط از طریق؛ گزینه‌های موجود: cpython3-mac-brew،‏ cpython3-mac-framework،‏ cpython3-posix،‏ cpython3-win،‏ graalpy-posix،‏ graalpy-win،‏ pypy3-posix،‏ pypy3-win،‏ rustpython-posix،‏ rustpython-win،‏ venv
dest دایرکتوری مقصد برای ساخت virtualenv
--clear False پیش از آغاز، در صورت وجود دایرکتوری مقصد آن را حذف کن (در غیر این صورت فایل‌ها رونویسی خواهند شد)
--no-vcs-ignore False دستورالعمل نادیده‌گیری VCS در دایرکتوری مقصد ایجاد نشود
--system-site-packages False دسترسی به دایرکتوری site-packages سیستم به محیط مجازی داده شود
--symlinks True تلاش برای استفاده از پیوندهای نمادین به‌جای رونوشت‌ها، زمانی که پیوند نمادین پیش‌فرض پلتفرم نیست
--copies, --always-copy False تلاش برای استفاده از رونوشت‌ها به‌جای پیوندهای نمادین، حتی زمانی که پیوند نمادین پیش‌فرض پلتفرم باشد
box center;
l|l|l.
core ⇒ گزینه‌های مشترک میان تمام seederها
--seeder 'app-data' روش نصب بسته‌های اولیه (seed)؛ انتخاب از میان: app-data، pip
--no-seed, --without-pip False عدم نصب بسته‌های اولیه (seed)
--no-download, --never-download True ارسال این گزینه برای غیرفعال کردن بارگیری جدیدترین pip/setuptools/wheel از PyPI
--download False ارسال این گزینه برای فعال کردن بارگیری جدیدترین pip/setuptools/wheel از PyPI
--extra-search-dir [] مسیری حاوی wheelها برای گسترش فهرست درونی wheel (می‌تواند ۱ یا چند بار مشخص شود)
--pip 'bundle' نسخهٔ pip جهت نصب به عنوان بذر (seed): embed، bundle، none یا نسخه‌ای مشخص
--setuptools 'none' نسخهٔ setuptools جهت نصب به عنوان بذر (seed): embed، bundle، none یا نسخه‌ای مشخص
--no-pip False عدم نصب pip
--no-setuptools False عدم نصب setuptools
--no-periodic-update False غیرفعال‌سازی به‌روزرسانی دوره‌ای (هر ۱۴ روز یک‌بار) wheelهای توکار
app-data ⇒ گزینه‌های ویژهٔ seeder مربوط به app-data
--symlink-app-data False ایجاد پیوند نمادین (symlink) برای بسته‌های پایتون از پوشهٔ app-data (نیازمند seed pip>=19.3)
box center;
l|l|l.
core ⇒ گزینه‌های مشترک میان همهٔ فعال‌سازها
--activators فهرست جداشده با کاما از فعال‌سازهای پشتیبانی‌شده فعال‌سازها برای ایجاد - پیش‌فرض تمام موارد پشتیبانی‌شده است؛ انتخاب از میان: xonsh، bash، batch، cshell، fish، nushell، powershell، python
--prompt یک پیشوند اعلان (prompt) جایگزین برای این محیط ارائه می‌دهد (مقدار . به معنای نام دایرکتوری کاری فعلی است)

مفسر در یک محیطِ ایجادشده به بیش از یک نام پاسخ می‌دهد، بنابراین اسکریپت یا ابزاری که هر یک از آن‌ها را به‌صورت سخت‌کد (hard-code) در خود دارد، به کار خود ادامه می‌دهد. نام‌های زیر مواردی هستند که سازنده‌های توکار (builtin creators) برای CPython می‌نویسند؛ PyPy، GraalPy و RustPython نیز ساختار مشابهی را تحت نام‌های اجراییِ خود دنبال می‌کنند.

عبارت {minor} نشان‌دهندهٔ نسخهٔ فرعی (minor version) مفسر هدف است؛ بنابراین python3.{minor} برای یک هدف CPython 3.14 به‌صورت python3.14 خوانده می‌شود.

دایرکتوری bin شامل یک ارجاع واقعی به مفسر میزبان است و باقی موارد را به آن پیوند (link) می‌دهد:

نام توضیحات
python به مفسر میزبان ارجاع می‌دهد.
python3 نام مستعار (Alias).
python3.{minor} نام مستعار شامل نسخهٔ فرعیِ مفسر هدف.
python3.{minor}t تنها در ساخت‌های بدون قفل سراسری (Free-threaded).
نام فایل اجرایی میزبان زمانی ظاهر می‌شود که میزبان نام دیگری داشته باشد، مانند pypy3.{minor}.

پوشهٔ Scripts به‌جای پیوندها نسخه‌های کپی را نگه می‌دارد، زیرا ایجاد پیوند نمادین (symlink) برای مفسر در آنجا غیرقابل‌اعتماد است (bpo-42013 https://bugs.python.org/issue42013):

نام توضیحات
python.exe به مفسر میزبان ارجاع می‌دهد.
python3.exe نام مستعار (Alias).
python3 نام مستعار بدون پسوند.
python3.{minor}t.exe تنها در ساخت‌های بدون قفل سراسری (Free-threaded).
pythonw.exe بدون باز کردن پنجرهٔ کنسول اجرا می‌شود.
pythonw3.exe نام مستعار برای pythonw.exe.
pythonw3.{minor}t.exe تنها در ساخت‌های بدون قفل سراسری (Free-threaded).
نام فایل اجرایی میزبان زمانی ظاهر می‌شود که میزبان نام دیگری داشته باشد، مانند python_d.exe.

در CPython 3.13 و نسخه‌های جدیدتر، python.exe به‌جای باینری مفسر، نسخه‌ای از هدایت‌کنندهٔ (redirector) venvlauncher.exe را از کتابخانهٔ استاندارد میزبان در بر دارد، و pythonw.exe از venvwlauncher.exe تأمین می‌شود. این هدایت‌کننده فایل pyvenv.cfg را می‌خواند و اجرای برنامه را به مفسر موجود در پیشوند پایه (base prefix) واگذار می‌کند؛ به همین دلیل است که محیط نیازی به کپی از DLLها ندارد. نام فایل اصلیِ آن در Scripts قرار نمی‌گیرد، که این رفتار مطابق با آن چیزی است که ماژول venv در کتابخانهٔ استاندارد ایجاد می‌کند.

نکته:

گزینهٔ --copies باعث می‌شود ساختار POSIX به‌جای پیوندها از رونوشت‌ها (کپی‌ها) استفاده کند. مجموعهٔ نام‌ها تغییری نمی‌کند.

رابط اصلی virtualenv برنامه خط فرمان است. با این حال، می‌توان از آن به صورت برنامه‌نویسی نیز از طریق تابع virtualenv.cli_run و کلاس Session استفاده کرد.

برای مثال‌های کاربردی Use virtualenv <> را ببینید.

ایجاد یک محیط مجازی با دریافت آرگومان‌های رابط خط فرمان.
پارامترها (Parameters)
نوع بازگشتی (Return type)
Session
بازمی‌گرداند (Returns)
شیء نشست حاصل از ایجاد (ساختار آن در حال حاضر آزمایشی است و ممکن است با اطلاع‌رسانی کوتاهی تغییر کند)
ایجاد یک نشست virtualenv (مشابه cli_run، با این تفاوت که این تابع فرایند ساخت را انجام نمی‌دهد). اگر فقط می‌خواهید وضعیت محیط مجازی را بدون ایجاد واقعی آن بررسی و پرس‌وجو کنید، از این تابع استفاده کنید.
پارامترها (Parameters)
نوع بازگشتی (Return type)
Session
بازمی‌گرداند (Returns)
شیء نشست حاصل از ایجاد (ساختار آن در حال حاضر آزمایشی است و ممکن است با اطلاع‌رسانی کوتاهی تغییر کند)

کلاس Session نمایانگر یک نشست ساخت virtualenv است و امکان دسترسی به ویژگی‌های محیط ایجادشده را فراهم می‌کند.

نمایانگر یک نشست ایجاد محیط مجازی است.
پارامترها (Parameters)
یک محیط مجازی بر پایه این مفسر مرجع ایجاد می‌کند.
سازنده (creator) مورداستفاده برای ساخت محیط مجازی (باید با مفسر سازگار باشد).
سازوکار مورداستفاده برای تأمین بسته‌های اولیه (pip، setuptools و wheel).
فعال‌سازهای مورداستفاده برای تولید اسکریپت‌های فعال‌سازی.

فضای نام گزینه‌ها که به سازنده‌های افزونه ارسال شده و از طریق CLI، متغیرهای محیطی و فایل‌های پیکربندی مقداردهی می‌شود.

تنظیم مقدار یک گزینه و ثبت منبع آن.
پارامترها
نوع بازگشتی
None https://docs.python.org/3/library/constants.html#None
منبعی که مقدار یک گزینهٔ مشخص را ارائه داده است بازمی‌گرداند.
پارامترها
key (str https://docs.python.org/3/library/stdtypes.html#str) -- نام گزینه
نوع بازگشتی
str https://docs.python.org/3/library/stdtypes.html#str | None https://docs.python.org/3/library/constants.html#None
مقدار بازگشتی
رشتهٔ منبع (برای نمونه "cli"، "env var"، "default")، یا در صورت عدم رهگیری None
سطح پرگویی، محاسبه‌شده به‌صورت verbose - quiet، محدودشده به صفر.
مقدار بازگشتی
سطح پرگویی، یا None اگر هنوز هیچ‌یک از --verbose و --quiet تجزیه نشده باشند

این صفحه به تشریح تصمیمات طراحی و مفاهیم پشت virtualenv می‌پردازد. تمرکز آن بر درک دلیل کارکرد امور به شیوهٔ فعلی است.

از زمان Python 3.3، کتابخانه استاندارد شامل ماژول venv است که امکان ایجاد محیط مجازی پایه‌ای را بر اساس PEP 405 https://www.python.org/dev/peps/pep-0405 فراهم می‌کند. ابزار uv https://docs.astral.sh/uv/pip/environments ابزاری جدیدتر و مبتنی بر Rust است که آن هم محیط‌های مجازی را از طریق uv venv ایجاد می‌کند.

virtualenv جایگاهی میانه دارد: سریع‌تر و پرامکانات‌تر از venv است، در حالی که همچنان یک راهکار خالص پایتونی با سامانه‌ای از افزونه‌ها برای توسعه‌پذیری باقی می‌ماند.

venv virtualenv uv https://docs.astral.sh/uv
عملکرد کندترین (+۶۰ ثانیه)؛ pip https://pip.pypa.io را به‌عنوان زیرفرآیند برای seed اجرا می‌کند. سریع؛ ایمیج‌های نصب ازپیش‌ساخته را کِش می‌کند، ساخت‌های بعدی کمتر از ۱ ثانیه. سریع‌ترین؛ پیاده‌سازی Rust، در حد میلی‌ثانیه. به‌طور پیش‌فرض pip/setuptools را seed نمی‌کند.
توسعه‌پذیری فاقد سامانه افزونه. سامانه افزونه برای کشف (discovery)، ساخت، seeding و فعال‌سازی. فاقد سامانه افزونه.
پشتیبانی بین‌نسخه‌ای فقط همان نسخه پایتونی که تحت آن اجرا می‌شود. هر پایتون نصب‌شده از طریق کشف خودکار (رجیستری، مدیریت‌شده توسط uv، متغیر PATH). هر پایتون نصب‌شده یا مدیریت‌شده توسط uv.
قابلیت ارتقا وابسته به انتشار نسخه‌های پایتون. مستقل از طریق PyPI https://pypi.org/project/virtualenv. مستقل از طریق چرخه انتشار خودش.
رابط برنامه‌نویسی (API) تنها تابع پایه‌ای create(). رابط برنامه‌نویسی کامل پایتون؛ می‌تواند محیط‌ها را بدون ایجادشان توصیف کند. استفاده‌شده توسط tox https://tox.readthedocs.io، poetry https://python-poetry.org، pipx https://pipx.pypa.io و غیره. فقط خط فرمان.
حاشیه‌نویسی نوع‌ها فاقد نشانگر py.typed؛ حاشیه‌نویسی‌های محدود. کاملاً نوع‌گذاری‌شده با نشانگر py.typed بر اساس PEP 561 https://peps.python.org/pep-0561؛ بررسی‌شده توسط ty https://docs.astral.sh/ty. نامربوط (باینری Rust).
مناسب‌ترین برای بدون وابستگی، نیازهای اولیه. توسعه‌پذیری افزونه، رابط برنامه‌نویسی (API)، سازگاری ابزارها (tox https://tox.readthedocs.io، virtualenvwrapper https://virtualenvwrapper.readthedocs.io). بیشترین سرعت، در صورت استفاده کنونی از uv برای مدیریت بسته.
[graph].SS نسخه‌های پشتیبانی‌شده پایتون

virtualenv میان مفسر host (پایتونی که خودِ virtualenv را اجرا می‌کند) و مفسر target (پایتونی که محیط مجازی برای آن ساخته می‌شود) تمایز قائل می‌شود. هنگامی که --python مشخص نشده باشد، مفسر میزبان (host) و هدف (target) یکسان هستند..SS مفسر میزبان

ابزار virtualenv به CPython یا PyPy نسخه 3.9 یا بالاتر به عنوان مفسر میزبان نیاز دارد. این موضوع توسط requires-python >= 3.9 در متاداده‌های بسته اعمال می‌شود.

مفسر هدف می‌تواند با مفسر میزبان متفاوت باشد. virtualenv می‌تواند برای هر مفسر Python که در سیستم شناسایی کند محیط‌های مجازی ایجاد کند، به شرط آن که یک creator (سازنده) منطبق برای آن وجود داشته باشد.

پیاده‌سازی پلتفرم‌ها یادداشت‌ها
CPython Linux, macOS, Windows نسخه 3.9+. ساخت‌های Free-threaded در 3.13+ پشتیبانی می‌شوند. شامل پشتیبانی از ساخت‌های دیباگ Windows، Microsoft Store، Homebrew و macOS framework.
PyPy Linux, macOS, Windows 3.9+.
GraalPy Linux, macOS, Windows 24.1+. پوشش آزمون حداقلی، به عنوان آزمایشی (experimental) علامت‌گذاری شده است.
RustPython Linux, macOS, Windows پوشش آزمون حداقلی، به عنوان آزمایشی (experimental) علامت‌گذاری شده است.

بسته‌های اولیه (pip، setuptools) برای CPython نسخه 3.9 تا 3.16 به صورت گنجانده‌شده (bundled) ارائه شده‌اند. مفسر هدفی که از بالاترین نسخه گنجانده‌شده جدیدتر باشد، مجدداً از جدیدترین بسته گنجانده‌شده استفاده می‌کند. مفسر هدفی که از قدیمی‌ترین نسخه گنجانده‌شده قدیمی‌تر باشد هیچ wheel سازگار گنجانده‌شده‌ای ندارد، بنابراین seederهای گنجانده‌شده پیش از ایجاد محیط آن را رد می‌کنند؛ برای یک محیط خالی گزینه --no-seed را مشخص کنید، یا seederی را انتخاب نمایید که بسته‌های wheel را برای آن نسخه ارائه می‌دهد.

بسته‌بندی در Python اغلب با یک مشکل اساسی مواجه است: برنامه‌های مختلف به نسخه‌های متفاوتی از یک کتابخانه یکسان نیاز دارند. اگر برنامه A به requests==2.25.1 نیاز داشته باشد اما برنامه B به requests==2.28.0 نیاز داشته باشد، نصب هر دوی آن‌ها در دایرکتوری سراسری site-packages باعث ایجاد تداخل می‌شود. در یک مکان مشخص تنها یک نسخه می‌تواند وجود داشته باشد.

ابزار virtualenv این مشکل را با ایجاد محیط‌های ایزوله Python برطرف می‌کند. هر محیط دارای دایرکتوری‌های نصب مخصوص به خود است و می‌تواند مجموعه‌ای از بسته‌های نصب‌شده خود را مستقل از سایر محیط‌ها و Python سیستم نگهداری کند.

ابزار virtualenv در دو مرحله مجزا کار می‌کند: [graph].INDENT 0.0

مرحله ۱: شناسایی یک مفسر Python
ابزار virtualenv ابتدا مشخص می‌کند از کدام مفسر Python به عنوان الگو برای محیط مجازی استفاده کند. به طور پیش‌فرض، از همان نسخه Python استفاده می‌کند که خود virtualenv روی آن در حال اجرا است. می‌توانید این رفتار را با پرچم --python بازنویسی کنید تا مفسر متفاوتی را مشخص نمایید.
مرحله ۲: ایجاد محیط مجازی
پس از شناسایی مفسر هدف، virtualenv محیط را در چهار مرحله ایجاد می‌کند:
1.
ایجاد یک فایل اجرایی Python منطبق با مفسر هدف
2.
نصب بسته‌های اولیه (pip، setuptools، wheel) جهت امکان‌پذیر ساختن نصب بسته‌ها
3.
نصب اسکریپت‌های فعال‌سازی برای پوسته‌های مختلف
4.
ایجاد فایل‌های نادیده‌گیری VCS (در حال حاضر .gitignore گیت، صرف‌نظر کردن با --no-vcs-ignore)

یک اصل طراحی مهم: محیط‌های مجازی خودکفا (self-contained) نیستند. یک نصب کامل Python شامل هزاران فایل است و کپی کردن تمامی آن‌ها در هر محیط مجازی موجب اتلاف منابع خواهد بود. در عوض، محیط‌های مجازی پوسته‌هایی سبک هستند که بیشتر محتوای خود را از Python سیستم قرض می‌گیرند. آن‌ها تنها شامل مواردی هستند که برای تغییر جهت دادن رفتار Python لازم است.

این نوع طراحی دو پیامد دارد:

  • ایجاد محیط سریع است زیرا تنها تعداد کمی فایل باید ایجاد شوند.
  • ارتقای Python سیستم ممکن است بر محیط‌های مجازی موجود تأثیر بگذارد، زیرا آن‌ها به کتابخانه استاندارد و افزونه‌های باینری Python سیستم ارجاع می‌دهند.

فایل اجرایی Python در یک محیط مجازی عملاً از مفسری که برای ایجاد آن استفاده شده ایزوله است، اما فایل‌های پشتیبان به اشتراک گذاشته شده‌اند.

هشدار:

اگر Python سیستم خود را ارتقا دهید، محیط‌های مجازی موجود همچنان نسخه قبلی را گزارش خواهند کرد (شماره نسخه در خود فایل اجرایی Python تعبیه شده است)، اما از کتابخانه استاندارد و اکستنشن‌های باینری نسخه جدید استفاده خواهند کرد. این وضعیت معمولاً بدون مشکل کار می‌کند، اما در نظر داشته باشید که محیط در عمل ترکیبی پیوندی از نسخه‌های قدیم و جدید Python را اجرا می‌کند.

پیش از ساخت یک محیط مجازی، virtualenv باید یک مفسر Python را پیدا کند. مفسر، نسخهٔ Python محیط مجازی، پیاده‌سازی آن (CPython، PyPy و غیره) و معماری آن (32-bit یا 64-bit) را مشخص می‌کند.

پرچم --python چندین قالب مشخص‌کننده را می‌پذیرد:

مشخص‌کنندهٔ مسیر (Path specifier)
یک مسیر مطلق یا نسبی به فایل اجرایی Python، مانند /usr/bin/python3.14 یا ./python.
مشخص‌کنندهٔ نسخه (Version specifier)
رشته‌ای با قالب {implementation}{version}{architecture}{machine} که در آن:
  • Implementation (پیاده‌سازی) شامل نویسه‌های الفبایی است (python به معنای هر پیاده‌سازی است؛ در صورت حذف، پیش‌فرض python خواهد بود).
  • Version (نسخه) اعدادی جداشده با نقطه است، که می‌تواند به صورت اختیاری با t برای ساخت‌های دارای free-threading همراه باشد.
  • Architecture (معماری) برابر با -64 یا -32 است (در صورت حذف، به معنای هر معماری خواهد بود).
  • Machine (ماشین) معماری مجموعه دستورالعمل پردازنده است، مانند -arm64، -x86_64، -aarch64 (در صورت حذف، به معنای هر ماشینی خواهد بود). نام‌های مستعار چندسکویی به‌طور خودکار یکسان‌سازی می‌شوند (amd64 ↔ x86_64، aarch64 ↔ arm64).

مثال‌ها:

  • python3.14.1 - هر پیاده‌سازی Python با نسخهٔ 3.14.1
  • 3 - هر پیاده‌سازی Python با نسخهٔ اصلی 3
  • 3.13t - هر پیاده‌سازی Python نسخهٔ 3.13 با ویژگی free-threading فعال
  • cpython3 - پیاده‌سازی CPython با نسخهٔ اصلی 3
  • pypy2 - پیاده‌سازی PyPy با نسخهٔ اصلی 2
  • cpython3.12-64-arm64 - نگارش CPython 3.12، معماری 64-bit، معماری ARM64
  • 3.11-64-x86_64 - هر پیاده‌سازی، نسخهٔ 3.11، معماری 64-bit، معماری x86_64
  • rustpython - پیاده‌سازی RustPython
مشخص‌کنندهٔ نسخه بر اساس PEP 440
محدودیت‌های نسخه با استفاده از عملگرهای PEP 440:
  • >=3.12 - هر نسخهٔ Python 3.12 یا بالاتر
  • ~=3.11.0 - سازگار با Python 3.11.0
  • cpython>=3.10 - نگارش CPython 3.10 یا بالاتر

هنگامی که یک مشخص‌کننده ارائه می‌دهید، virtualenv با استفاده از این راهبرد به جستجوی مفسرهای منطبق می‌پردازد: [نمودار]

1.
Windows Registry (تنها در Windows): بررسی نصب‌های ثبت‌شدهٔ Python طبق PEP 514 https://www.python.org/dev/peps/pep-0514.
2.
نصب‌های مدیریت‌شده با uv: بررسی متغیر محیطی UV_PYTHON_INSTALL_DIR یا دایرکتوری‌های ویژهٔ هر پلتفرم uv Python برای یافتن نصب‌های مدیریت‌شدهٔ Python.
3.
جستجو در PATH: جستجو برای فایل‌های اجرایی در متغیر محیطی PATH با نام‌های منطبق بر مشخصات داده‌شده.

مدیرهای نسخه مانند pyenv https://github.com/pyenv/pyenv، ‏mise https://mise.jdx.dev و asdf https://asdf-vm.com اسکریپت‌های واسط (shim) سبکی را در PATH قرار می‌دهند که درخواست‌ها را به باینری واقعی Python محول می‌کنند. هنگامی که virtualenv یک مفسر Python را با اجرای آن در قالب یک زیرپردازش شناسایی می‌کند، ممکن است این shimها نسخهٔ نادرستی از Python را انتخاب کنند (معمولاً Python سیستم)؛ چرا که منطق تفکیک shim به وضعیت محیط پوسته وابسته است که به‌طور کامل به پردازش‌های فرزند منتقل نمی‌شود.

ابزار virtualenv با بررسی اینکه آیا فایل اجرایی نامزد در یک دایرکتوری شناخته‌شدهٔ shim ($PYENV_ROOT/shims، $MISE_DATA_DIR/shims یا $ASDF_DATA_DIR/shims) قرار دارد یا خیر، shimها را شناسایی می‌کند. هنگامی که یک shim شناسایی می‌شود، virtualenv آن را دور زده و باینری واقعی را مستقیماً در دایرکتوری versions مدیر نسخه و با استفاده از نسخهٔ فعال حاصل از موارد زیر پیدا می‌کند:

1.
متغیر محیطی PYENV_VERSION (برای چندین نسخه با دونقطه از هم جدا می‌شوند).
2.
یک فایل .python-version در دایرکتوری جاری یا هر یک از دایرکتوری‌های والد.
3.
فایل نسخهٔ سراسری در $PYENV_ROOT/version.

این سازوکار میان pyenv، mise و asdf مشترک است، بنابراین منطق تفکیک یکسانی برای هر سه کار می‌کند.

هشدار:

محیط‌های مجازی معمولاً به کتابخانهٔ استاندارد Python سیستم ارجاع می‌دهند. اگر Python سیستم را ارتقا دهید، محیط مجازی نسخهٔ قدیمی (جاسازی‌شده در فایل اجرایی Python خود) را گزارش خواهد داد، اما در عمل از محتوای کتابخانهٔ استاندارد نسخهٔ جدید استفاده می‌کند. این موضوع می‌تواند هنگام عیب‌یابی رفتارهای وابسته به نسخه باعث سردرگمی شود.

اگر از Python یک محیط مجازی به‌عنوان هدف برای ساخت یک محیط مجازی دیگر استفاده کنید، virtualenv نسخهٔ Python سیستم را شناسایی کرده و محیطی منطبق بر نسخهٔ واقعی (ارتقایافته) ایجاد می‌کند، نه نسخه‌ای که توسط محیط مجازی گزارش شده است.

ایجادکننده‌ها مسئول ساختاردهی به محیط مجازی هستند. ابزار virtualenv از دو نوع ایجادکننده پشتیبانی می‌کند:

ایجادکنندهٔ venv (venv creator)
این ایجادکننده کل فرآیند ساخت را پیرو PEP 405 https://www.python.org/dev/peps/pep-0405 به ماژول venv کتابخانهٔ استاندارد واگذار می‌کند. ایجادکنندهٔ venv نیازمند ایجاد یک زیرفرآیند برای فراخوانی ماژول venv است، مگر اینکه virtualenv در Python سیستم نصب شده باشد.

سربار ناشی از زیرفرآیند می‌تواند قابل‌توجه باشد، به‌ویژه در Windows که ایجاد فرآیند در آن پرهزینه است.

ایجادکنندهٔ توکار (builtin creator)
این ایجادکننده بدان معناست که virtualenv خود فرآیند ایجاد را با دانستن دقیق این‌که چه فایل‌هایی باید ایجاد شوند و به کدام فایل‌های سیستم باید ارجاع داده شود، انجام می‌دهد. ایجادکنندهٔ builtin در واقع خانواده‌ای از ایجادکننده‌های تخصصی برای ترکیب‌های مختلف پیاده‌سازی‌های Python (نظیر CPython، PyPy، GraalPy و RustPython) و بسترها (Windows، POSIX) است. نام builtin یک نام مستعار است که نخستین ایجادکنندهٔ توکار دردسترس را برای محیط هدف انتخاب می‌کند.

از آنجا که ایجادکننده‌های توکار نیازی به فراخوانی زیرفرآیند ندارند، عموماً سریع‌تر از ایجادکنندهٔ venv عمل می‌کنند.

[graph]

ابزار virtualenv به‌طور پیش‌فرض در صورت دردسترس بودن ایجادکنندهٔ توکار برای محیط هدف، از آن استفاده می‌کند و در غیر این صورت به ایجادکنندهٔ venv بازمی‌گردد.

صرف‌نظر از اینکه کدام ایجادکننده اجرا شود، مفسر در نهایت تحت چندین نام قابل‌دسترس خواهد بود که در چیدمان محیط (Environment layout) <> فهرست شده‌اند. ابزارهای مختلف نام‌های متفاوتی را فراخوانی می‌کنند - ممکن است یک خط شِبانگ (shebang) به python اشاره کند، یا یک وظیفهٔ CI نام نسخه‌دار را فراخوانی نماید - و محیطی که تنها یکی از آن‌ها را ارائه دهد، عملکرد بقیه را مختل می‌کند. ایجادکننده‌های توکار نام‌های دارای نسخه را از مفسر هدف برمی‌دارند و نام فایل اجراییِ خود میزبان را نیز اضافه می‌کنند؛ بنابراین میزبانی با نام pypy3.11 یا python_d.exe همچنان با همان نامی که فراخوانندگانش استفاده می‌کنند در دسترس باقی می‌ماند.

در Windows فایل‌ها به‌جای پیوند نمادین رونوشت (کپی) می‌شوند، چرا که پیوند نمادین مفسر در آنجا قابل‌اعتماد نیست (bpo-42013 https://bugs.python.org/issue42013). از CPython 3.13 به بعد، فایلی که کپی می‌شود خود مفسر نیست، بلکه بازهدایت‌گر venvlauncher.exe برگرفته از کتابخانهٔ استاندارد میزبان است. این بازهدایت‌گر فایل pyvenv.cfg را می‌خواند و کنترل را به پیشوند پایه منتقل می‌کند، که این امر مانع از کپی شدن فایل‌های DLL و فایل zip کتابخانهٔ استاندارد در تک‌تک محیط‌ها می‌شود. اینکه فایل کپی‌شده چه نامی دارد تفاوتی در مقصد نهایی ایجاد نمی‌کند، زیرا بازهدایت‌گر هدف خود را بر اساس مقداری که درون آن کامپایل شده تعیین می‌کند، نه از روی نام فایل خودش.

پس از ایجاد ساختار محیط مجازی، virtualenv بسته‌های اولیه را که مدیریت بسته را در محیط ممکن می‌سازند، نصب می‌کند. بسته‌های اولیه عبارت‌اند از:

  • pip - نصب‌کنندهٔ بسته برای Python (همیشه نصب می‌شود).
  • setuptools - کتابخانهٔ توسعه و نصب بسته (به‌طور پیش‌فرض در Python 3.12+ غیرفعال است).

ابزار virtualenv از دو روش کاشت با ویژگی‌های عملکردی بسیار متفاوت پشتیبانی می‌کند:

بذرپاش pip (pip seeder)
این روش با ایجاد یک فرآیند فرزند pip، از بستهٔ wheel همراه pip برای نصب بسته‌های اولیه استفاده می‌کند. این زیرفرآیند یک نصب کامل شامل از حالت فشرده خارج کردن بسته‌های wheel و تولید متاداده را انجام می‌دهد. این روش قابل‌اعتماد اما کند است و معمولاً ۹۸٪ از کل زمان ساخت محیط مجازی را مصرف می‌کند.
بذرپاش app-data (app-data seeder)
این روش ایمیج‌های نصبیِ با قابلیت استفادهٔ مجدد را در دایرکتوری داده‌های برنامهٔ کاربر ایجاد می‌کند. نخستین باری که محیطی را با نسخه‌های مشخصی از بسته‌های اولیه ایجاد می‌کنید، بذرپاش app-data ایمیج‌های نصب کاملی را ساخته و در حافظهٔ نهان ذخیره می‌کند. در ایجاد محیط‌های بعدی، این ایمیج‌های از پیش ساخته‌شده صرفاً به دایرکتوری site-packages محیط مجازی پیوند داده شده یا کپی می‌شوند.

مقایسهٔ عملکرد در ایجاد محیط‌های مجازی: [graph]

در بسترهایی که به‌طور بهینه از پیوندهای نمادین پشتیبانی می‌کنند (مانند Linux و macOS)، بذرپاش app-data کاشتی تقریباً آنی را فراهم می‌کند.

می‌توانید با استفاده از متغیر محیطی VIRTUALENV_OVERRIDE_APP_DATA محل حافظهٔ نهان را بازنویسی کنید.

هر دو روش کاشت نیازمند فایل‌های wheel برای بسته‌های اولیه هستند. ابزار virtualenv فایل‌های wheel را با استفاده از یک سیستم اولویت‌بندی به دست می‌آورد: [graph]

بسته‌های wheel توکار (Embedded wheels)
ابزار virtualenv با مجموعه‌ای از فایل‌های wheel عرضه می‌شود که مستقیماً در بسته گنجانده شده‌اند. این بسته‌ها همراه با نگارش virtualenv آزمایش شده‌اند و مجموعه‌ای پایه از بسته‌های اولیه را ارائه می‌دهند. نسخه‌های مختلف Python به نسخه‌های متفاوتی از بسته‌ها نیاز دارند، ازاین‌رو virtualenv چندین بستهٔ wheel مختلف را در خود گنجانده تا دامنهٔ گسترده‌ای از نسخه‌های Python را پشتیبانی کند.
بسته‌های wheel توکار ارتقایافته (Upgraded embedded wheels)
کاربران می‌توانند با اجرای virtualenv به همراه پرچم --upgrade-embed-wheels بسته‌های wheel توکار را به‌صورت دستی ارتقا دهند. این کار نسخه‌های جدیدتر بسته‌های اولیه را از PyPI دریافت کرده و آن‌ها را در دایرکتوری داده‌های برنامهٔ کاربر ذخیره می‌کند. فراخوانی‌های بعدی virtualenv به‌جای بسته‌های توکار پیش‌فرض، از این بسته‌های wheel ارتقایافته استفاده خواهند کرد.

همچنین virtualenv می‌تواند ارتقاهای خودکار دوره‌ای را انجام دهد (پایین‌تر را ببینید).

دایرکتوری‌های جستجوی اضافی (Extra search directories)
کاربران می‌توانند با استفاده از پرچم --extra-search-dir دایرکتوری‌های دیگری را که حاوی فایل‌های wheel هستند مشخص کنند. این قابلیت در محیط‌های بدون دسترسی به اینترنت (air-gapped) یا هنگام استفاده از ساخت‌های سفارشی بسته‌ها مفید است.
دانلود از PyPI (PyPI download)
اگر هیچ بستهٔ wheel مناسبی در مکان‌های بالا یافت نشود، یا اگر پرچم --download تنظیم شده باشد، virtualenv از pip برای دانلود آخرین نسخهٔ سازگار از PyPI استفاده خواهد کرد.

برای به‌روز نگه‌داشتن بسته‌های اولیه (seed packages) تا حدی معقول بدون نیاز به ارتقای دستی virtualenv یا اجرای --upgrade-embed-wheels توسط کاربران، virtualenv یک سامانه به‌روزرسانی خودکار دوره‌ای را پیاده‌سازی می‌کند: [graph]

دوره انتظار ۲۸ روزه کاربران را در برابر دریافت خودکار بسته‌های تازه‌منتشرشده‌ای که ممکن است حاوی باگ باشند محافظت می‌کند. تأخیر ۱ ساعته پس از بارگیری تضمین می‌کند که سامانه‌های یکپارچه‌سازی مداوم در میانه اجرا از نسخه‌های متفاوتی از بسته‌ها استفاده نکنند، که می‌تواند باعث شکست‌های گیج‌کننده در آزمون‌ها شود.

می‌توانید سازوکار به‌روزرسانی دوره‌ای را با پرچم --no-periodic-update غیرفعال کنید.

توزیع‌های سیستم‌عامل و مدیرهای بسته گاهی نیاز دارند نسخه‌های بسته‌های اولیه مورد استفاده virtualenv را سفارشی‌سازی کنند. آن‌ها می‌خواهند بسته‌های همراه virtualenv را با نسخه‌های بسته‌های سیستم هماهنگ نمایند.

توزیع‌ها می‌توانند پودمان virtualenv.seed.wheels.embed را وصله کنند و تابع get_embed_wheel را با پیاده‌سازی خود که فایل‌های wheel ارائه‌شده توسط توزیع را برمی‌گرداند، جایگزین نمایند. اگر بخواهند از مجموعه آزمون‌های virtualenv برای اعتبارسنجی استفاده کنند، باید متغیرهای BUNDLE_FOLDER، BUNDLE_SUPPORT، MIN، MAX و OLDEST_SUPPORTED را نیز فراهم کنند. متغیر OLDEST_SUPPORTED (شکل تجزیه‌شده MIN) کفی را تعیین می‌کند که پایین‌تر از آن، seederهای همراه از مقداردهی اولیه خودداری می‌کنند؛ بنابراین توزیعی که wheelها را برای یک Python قدیمی‌تر همراه می‌کند، باید این مقدار را متناسب با آن کاهش دهد.

توزیع‌ها همچنین باید وصله‌کردن virtualenv.seed.embed.base_embed.PERIODIC_UPDATE_ON_BY_DEFAULT به False را مد نظر قرار دهند، تا به مدیر بسته سیستم اجازه دهند به‌روزرسانی‌های بسته‌های اولیه را به جای سازوکار به‌روزرسانی دوره‌ای virtualenv کنترل کند. کاربران همچنان می‌توانند ارتقاها را به‌صورت دستی از طریق --upgrade-embed-wheels درخواست کنند، اما به‌روزرسانی‌های خودکار با بسته‌های مدیریت‌شده توسط سیستم تداخل نخواهند داشت.

اسکریپت‌های فعال‌سازی، محیط پوسته فعلی را برای اولویت‌دادن به فایل‌های اجرایی محیط مجازی تغییر می‌دهند. این صرفاً یک سازوکار برای راحتی کار است - شما همواره می‌توانید بدون فعال‌سازی از مسیرهای مطلق به فایل‌های اجرایی محیط مجازی استفاده کنید.

آنچه فعال‌سازی انجام می‌دهد: [graph].INDENT 0.0

تغییر PATH
اسکریپت فعال‌سازی، دایرکتوری bin محیط مجازی (Scripts در ویندوز) را به ابتدای متغیر محیطی PATH اضافه می‌کند. این امر تضمین می‌کند که هنگام اجرای python، pip یا سایر برنامه‌های اجرایی، پوسته ابتدا نسخه‌های مربوط به محیط مجازی را بیابد.
متغیرهای محیطی
فعال‌سازی چندین متغیر محیطی را مقداردهی می‌کند:
  • VIRTUAL_ENV - مسیر مطلق به دایرکتوری محیط مجازی.
  • VIRTUAL_ENV_PROMPT - پیشوند اعلان (نام محیط یا مقدار سفارشی از --prompt).
  • PKG_CONFIG_PATH - برای شامل شدن دایرکتوری lib/pkgconfig محیط مجازی تغییر می‌یابد.
تغییر اعلان خط فرمان
به‌طور پیش‌فرض، فعال‌سازی نام محیط را به ابتدای اعلان پوسته اضافه می‌کند که معمولاً به‌صورت (venv) پیش از اعلان عادی نمایش داده می‌شود. این نشانگر بصری به شما یادآوری می‌کند کدام محیط فعال است. می‌توانید هنگام ساخت محیط این مورد را با پرچم --prompt سفارشی کنید، یا با مقداردهی متغیر محیطی VIRTUAL_ENV_DISABLE_PROMPT آن را کاملاً غیرفعال سازید.
غیرفعال‌سازی
اسکریپت‌های فعال‌سازی همچنین دستور deactivate را فراهم می‌کنند که تغییرات را معکوس می‌کند، PATH اصلی شما را بازیابی کرده و متغیرهای محیطی و تغییرات اعلان را حذف می‌نماید.


ابزار virtualenv اسکریپت‌های فعال‌سازی را برای چندین پوسته فراهم می‌کند:

نکته:

در ویندوز ۷ و جدیدتر، سیاست اجرای پیش‌فرض در PowerShell برابر با Restricted است که از اجرای اسکریپت activate.ps1 جلوگیری می‌کند. می‌توانید با تغییر این سیاست اجرا به اسکریپت‌های تولیدشده محلی اجازه اجرا بدهید:
Set-ExecutionPolicy RemoteSigned

از آنجا که virtualenv فایل activate.ps1 را به‌طور محلی برای هر محیط تولید می‌کند، PowerShell آن را به جای یک اسکریپت از راه دور، اسکریپتی محلی در نظر گرفته و اجرای آن را تحت سیاست RemoteSigned مجاز می‌داند.

به یاد داشته باشید: فعال‌سازی اختیاری است. دستورهای زیر با یکدیگر معادل هستند:

# With activation
source venv/bin/activate
python script.py
deactivate
# Without activation
venv/bin/python script.py

برای بررسی عمیق‌تر سازوکار درونی فعال‌سازی، به پست وبلاگ Allison Kaptur با عنوان There's no magic: virtualenv edition در https://www.recurse.com/blog/14-there-is-no-magic-virtualenv-edition مراجعه کنید که توضیح می‌دهد چگونه virtualenv از PATH و PYTHONHOME برای جداسازی محیط‌های مجازی استفاده می‌کند..SS "همچنین ببینید (SEE ALSO)"

  • استفاده از virtualenv <> - راهنماهای کاربردی برای کارهای متداول virtualenv.
  • خط فرمان <> - مستندات مرجع کامل CLI.

ابزار virtualenv می‌تواند از طریق پلاگین‌ها با استفاده از entry pointهای پایتون گسترش یابد. پلاگین‌ها به‌طور خودکار از محیط پایتونی که virtualenv در آن نصب شده است شناسایی می‌شوند و به شما امکان می‌دهند نحوه ایجاد، بارگذاری بسته‌های اولیه (seed) و فعال‌سازی محیط‌های مجازی را سفارشی‌سازی کنید.

ابزار virtualenv چهار نقطه گسترش را از طریق گروه‌های entry point فراهم می‌کند:

پلاگین‌های شناسایی مفسر پایتون. این پلاگین‌ها مفسرهای پایتونی را که به‌عنوان پایه برای ساخت محیط‌های مجازی استفاده خواهند شد، مکان‌یابی و شناسایی می‌کنند.
پلاگین‌های سازنده محیط مجازی. این پلاگین‌ها ساختار واقعی محیط مجازی، از جمله کپی کردن یا ایجاد پیوند نمادین (symlink) مفسر پایتون و کتابخانه استاندارد را مدیریت می‌کنند.
پلاگین‌های نصب بسته‌های اولیه (seed). این پلاگین‌ها بسته‌های آغازین (مانند pip، setuptools و wheel) را در محیط‌های مجازی تازه ایجادشده نصب می‌کنند.
پلاگین‌های اسکریپت فعال‌سازی شل. این پلاگین‌ها اسکریپت‌های فعال‌سازی ویژه هر شل را ایجاد می‌کنند که محیط را برای استفاده از محیط مجازی تغییر می‌دهند.

تمامی نقاط گسترش از یک الگوی مشترک پیروی می‌کنند: virtualenv ورودی‌های ثبت‌شده (entry points) را شناسایی می‌کند، گزینه‌های خط فرمان (CLI) را بر اساس آن‌ها می‌سازد، و پیاده‌سازی‌های انتخاب‌شده را در حین ساخت محیط اجرا می‌کند.

این آموزش مراحل ایجاد یک پلاگین شناسایی ساده را که مفسرهای پایتون مدیریت‌شده توسط pyenv را پیدا می‌کند، شرح می‌دهد.

یک بسته جدید پایتون با ساختار زیر ایجاد کنید:

virtualenv-pyenv/
├── pyproject.toml
└── src/
    └── virtualenv_pyenv/
        └── __init__.py

در فایل pyproject.toml، پلاگین خود را به عنوان یک entry point در زیر گروه virtualenv.discovery تعریف کنید:

[project]
name = "virtualenv-pyenv"
version = "0.1.0"
dependencies = ["virtualenv>=20"]
[project.entry-points."virtualenv.discovery"]
pyenv = "virtualenv_pyenv:PyEnvDiscovery"
[build-system]
requires = ["setuptools>=61"]
build-backend = "setuptools.build_meta"

در فایل src/virtualenv_pyenv/__init__.py، پلاگین شناسایی را با ایجاد زیرکلاسی از Discover پیاده‌سازی کنید:

from __future__ import annotations
import subprocess
from argparse import ArgumentParser
from pathlib import Path
from virtualenv.config.cli.parser import VirtualEnvOptions
from virtualenv.discovery.discover import Discover
from virtualenv.discovery.py_info import PythonInfo
class PyEnvDiscovery(Discover):
    def __init__(self, options: VirtualEnvOptions) -> None:
        super().__init__(options)
        self.python_spec = options.python if options.python else "python"
    @classmethod
    def add_parser_arguments(cls, parser: ArgumentParser) -> None:
        parser.add_argument(
            "--python",
            dest="python",
            metavar="py",
            type=str,
            default=None,
            help="pyenv Python version to use (e.g., 3.11.0)",
        )
    def run(self) -> PythonInfo | None:
        try:
            result = subprocess.run(
                ["pyenv", "which", "python"],
                capture_output=True,
                text=True,
                check=True,
            )
            python_path = Path(result.stdout.strip())
            return PythonInfo.from_exe(str(python_path))
        except (subprocess.CalledProcessError, FileNotFoundError) as e:
            raise RuntimeError(f"Failed to locate pyenv Python: {e}") from e

افزونه خود را در حالت توسعه در کنار virtualenv نصب کنید:

$ pip install -e virtualenv-pyenv/

با اجرای دستور زیر، شناسایی افزونه توسط virtualenv را بررسی کنید:

$ virtualenv --discovery help

خروجی باید pyenv را به عنوان یک سازوکار شناساییِ دردسترس فهرست کند. اکنون می‌توانید از آن استفاده کنید:

$ virtualenv --discovery=pyenv myenv
created virtual environment CPython3.11.0.final.0-64 in 234ms
  creator CPython3Posix(dest=/path/to/myenv, clear=False, no_vcs_ignore=False, global=False)
  seeder FromAppData(download=False, pip=bundle, setuptools=bundle, wheel=bundle, via=copy, app_data_dir=/path)
    added seed packages: pip==23.0, setuptools==65.5.0, wheel==0.38.4
  activators BashActivator,CShellActivator,FishActivator,NushellActivator,PowerShellActivator,PythonActivator

این صفحه راهنماهایی وظیفه‌محور را برای ساخت هر نوع افزونه virtualenv فراهم می‌کند.

افزونه‌های شناسایی، مفسرهای Python را پیدا می‌کنند. افزونه خود را ذیل گروه نقطه ورود virtualenv.discovery ثبت کنید.

رابط Discover را پیاده‌سازی کنید:

from __future__ import annotations
from argparse import ArgumentParser
from virtualenv.config.cli.parser import VirtualEnvOptions
from virtualenv.discovery.discover import Discover
from virtualenv.discovery.py_info import PythonInfo
class CustomDiscovery(Discover):
    @classmethod
    def add_parser_arguments(cls, parser: ArgumentParser) -> None:
        parser.add_argument("--custom-opt", help="custom discovery option")
    def __init__(self, options: VirtualEnvOptions) -> None:
        super().__init__(options)
        self.custom_opt = options.custom_opt
    def run(self) -> PythonInfo | None:
        # Locate Python interpreter and return PythonInfo
        return PythonInfo.from_exe(str(self._find_python()))
    def _find_python(self) -> str:
        # Implementation-specific logic
        ...

نقطه ورود را ثبت کنید:

[virtualenv.discovery]
custom = your_package.discovery:CustomDiscovery

افزونه‌های creator ساختار محیط مجازی را می‌سازند. آنها را تحت virtualenv.create ثبت کنید.

رابط Creator را پیاده‌سازی کنید:

from __future__ import annotations
from argparse import ArgumentParser
from virtualenv.app_data.base import AppData
from virtualenv.config.cli.parser import VirtualEnvOptions
from virtualenv.create.creator import Creator, CreatorMeta
from virtualenv.discovery.py_info import PythonInfo
class CustomCreator(Creator):
    @classmethod
    def add_parser_arguments(
        cls,
        parser: ArgumentParser,
        interpreter: PythonInfo,
        meta: CreatorMeta,
        app_data: AppData,
    ) -> None:
        parser.add_argument("--custom-creator-opt", help="custom creator option")
    def __init__(self, options: VirtualEnvOptions, interpreter: PythonInfo) -> None:
        super().__init__(options, interpreter)
        self.custom_opt = options.custom_creator_opt
    def create(self) -> None:
        # Create directory structure
        self.bin_dir.mkdir(parents=True, exist_ok=True)
        # Copy or symlink Python executable
        self.install_python()
        # Set up site-packages
        self.install_site_packages()
        # Write pyvenv.cfg
        self.set_pyenv_cfg()

نقطه ورود (entry point) را با استفاده از یک الگوی نام‌گذاری که با پلتفرم و نسخهٔ پایتون مطابقت دارد ثبت کنید:

[virtualenv.create]
cpython3-posix = virtualenv.create.via_global_ref.builtin.cpython.cpython3:CPython3Posix
cpython3-win = virtualenv.create.via_global_ref.builtin.cpython.cpython3:CPython3Windows

افزونه‌های seeder بسته‌های اولیه را درون محیط مجازی نصب می‌کنند. آنها را تحت virtualenv.seed ثبت کنید.

متد cannot_seed را بازنویسی کنید تا مفسرهای هدفی که seeder از آن‌ها پشتیبانی نمی‌کند رد شوند. کلاس پایه برای هر مفسر مقدار None را برمی‌گرداند؛ در عوض یک پیام بازگردانید تا سازوکار انتخاب، seeder را پیش از ایجاد محیط رد کرده و پیام شما را به کاربر نشان دهد. به این ترتیب، یک افزونه می‌تواند به نسخه‌هایی از پایتون سرویس دهد که seederهای همراه دیگر فایلهای wheel را برای آن‌ها ارائه نمی‌کنند، مانند نسخه‌ای که دورهٔ پشتیبانی آن به پایان رسیده است.

رابط Seeder را پیاده‌سازی کنید:

from __future__ import annotations
from argparse import ArgumentParser
from virtualenv.app_data.base import AppData
from virtualenv.config.cli.parser import VirtualEnvOptions
from virtualenv.create.creator import Creator
from virtualenv.discovery.py_info import PythonInfo
from virtualenv.seed.seeder import Seeder
class CustomSeeder(Seeder):
    @classmethod
    def add_parser_arguments(
        cls, parser: ArgumentParser, interpreter: PythonInfo, app_data: AppData
    ) -> None:
        parser.add_argument("--custom-seed-opt", help="custom seeder option")
    @classmethod
    def cannot_seed(cls, interpreter: PythonInfo) -> str | None:
        # ship wheels down to Python 3.6, for example
        if interpreter.version_info[:2] >= (3, 6):
            return None
        return "custom seeder ships wheels only for Python 3.6 and later"
    def __init__(self, options: VirtualEnvOptions, enabled: bool) -> None:
        super().__init__(options, enabled)
        self.custom_opt = options.custom_seed_opt
    def run(self, creator: Creator) -> None:
        # Install packages into creator.bin_dir / creator.script("pip")
        self._install_packages(creator)
    def _install_packages(self, creator: Creator) -> None:
        # Implementation-specific logic
        ...

نقطه ورود را ثبت کنید:

[virtualenv.seed]
custom = your_package.seed:CustomSeeder

افزونه‌های فعال‌ساز اسکریپت‌های فعال‌سازی پوسته را تولید می‌کنند. آن‌ها را ذیل virtualenv.activate ثبت کنید.

رابط Activator را پیاده‌سازی کنید:

from __future__ import annotations
from pathlib import Path
from virtualenv.activation.activator import Activator
from virtualenv.create.creator import Creator
class CustomShellActivator(Activator):
    def generate(self, creator: Creator) -> list[Path]:
        # Generate activation script content
        script_content = self._render_template(creator)
        # Write to activation directory
        dest = creator.bin_dir / self.script_name
        dest.write_text(script_content)
        return [dest]
    def _render_template(self, creator: Creator) -> str:
        # Return activation script content
        return f"""
        # Custom shell activation script
        export VIRTUAL_ENV="{creator.dest}"
        export PATH="{creator.bin_dir}:$PATH"
        """
    @property
    def script_name(self) -> str:
        return "activate.custom"

نقطهٔ ورود را ثبت کنید:

[virtualenv.activate]
bash = virtualenv.activation.bash:BashActivator
fish = virtualenv.activation.fish:FishActivator
custom = your_package.activation:CustomShellActivator

برای اعلان نقاط ورود از pyproject.toml استفاده کنید:

[project]
name = "virtualenv-custom-plugin"
version = "1.0.0"
dependencies = ["virtualenv>=20.0.0"]
[project.entry-points."virtualenv.discovery"]
custom = "virtualenv_custom.discovery:CustomDiscovery"
[project.entry-points."virtualenv.create"]
custom-posix = "virtualenv_custom.creator:CustomCreator"
[project.entry-points."virtualenv.seed"]
custom = "virtualenv_custom.seeder:CustomSeeder"
[project.entry-points."virtualenv.activate"]
custom = "virtualenv_custom.activator:CustomActivator"
[build-system]
requires = ["setuptools>=61"]
build-backend = "setuptools.build_meta"

افزونهٔ خود را در کنار virtualenv نصب کنید:

$ pip install virtualenv-custom-plugin

یا در حالت توسعه:

$ pip install -e /path/to/virtualenv-custom-plugin

افزونهٔ خود را با ساخت یک محیط مجازی آزمایش کنید:

$ virtualenv --discovery=custom --creator=custom-posix --seeder=custom --activators=custom test-env

این صفحه رابط‌هایی را مستند می‌کند که افزونه‌ها باید پیاده‌سازی کنند.

افزونه‌های شناسایی، مفسرهای Python را برای ایجاد محیط‌های مجازی پیدا می‌کنند.

پارامترها
options (VirtualEnvOptions <#virtualenv.config.cli.parser.VirtualEnvOptions>)
مفسر بازگردانده‌شده توسط run()، به‌صورت کش‌شده (cached).

افزونه‌های شناسایی یک شیء PythonInfo بازمی‌گردانند که مفسرِ یافت‌شده را توصیف می‌کند.

شامل اطلاعات مربوط به یک مفسر Python است.
install_path(key) مسیر نصب نسبی را برای key طرح نصب مشخص برمی‌گرداند.
پارامترها
key (str https://docs.python.org/3/library/stdtypes.html#str) -- کلید طرح نصب sysconfig (مانند "scripts"، "purelib").
نوع بازگشتی
str https://docs.python.org/3/library/stdtypes.html#str
نسخه کامل به‌صورت رشته major.minor.micro (مانند 3.13.2).
نسخه انتشار به‌صورت رشته major.minor (مانند 3.13).
نام فایل اجرایی پایتون به‌صورت pythonX.Y (مانند python3.13).
True اگر این مفسر در یک virtualenv قدیمی اجرا شود (دارای real_prefix باشد).
True اگر این مفسر درون یک venv بر پایه PEP 405 اجرا شود (دارای base_prefix باشد).
مسیر نصب sysconfig را برای یک key طرح برمی‌گرداند، همراه با امکان جایگزینی اختیاری متغیرهای پیکربندی.
پارامترها
نوع بازگشتی
str https://docs.python.org/3/library/stdtypes.html#str
مسیر دایرکتوری include سیستم برای سرآیندهای C.
پیشوند پایتون سیستمی که این مفسر بر پایه آن است.
پیشوند اجرایی پایتون سیستمی که این مفسر بر پایه آن است.
فایل اجرایی پایتون سیستمی که این مفسر بر پایه آن است.

مقدار system_executable تا زمانی که resolve_to_system() زنجیره پیشوند را پیمایش کند None باقی می‌ماند، بنابراین خواندن آن هر فراخواننده‌ای را ناچار می‌کند مقداری را که فرایند کشف قبلاً تثبیت کرده است محدود کند. سازوکار جایگزین در اینجا با آنچه خود فرایند تفکیک در هنگام ارجاع یک پیشوند به مفسر خودش می‌نویسد، مطابقت دارد.

معماری مجموعه دستورالعمل (ISA) مشتق‌شده از sysconfig.get_platform() https://docs.python.org/3/library/sysconfig.html#sysconfig.get_platform.
یک رشته مشخصات که این مفسر را شناسایی می‌کند (مانند CPython3.13.2-64-arm64).
پاک‌سازی تمام اطلاعات کش‌شده مفسر از cache.
پارامترها
cache (PyInfoCache) -- مخزن کش برای پاک‌سازی.
نوع بازگشتی
None https://docs.python.org/3/library/constants.html#None
بررسی اینکه آیا یک مشخصه داده‌شده می‌تواند توسط این نمونه مفسر پایتون برآورده شود یا خیر.
پارامترها
نوع بازگشتی
bool https://docs.python.org/3/library/functions.html#bool
یافتن اطلاعات مفسر میزبان فعلی.
پارامترها
cache (PyInfoCache | None https://docs.python.org/3/library/constants.html#None) -- کش متادیتای مفسر؛ زمانی که None باشد نتایج کش نمی‌شوند.
نوع بازگشتی
PythonInfo
یافتن اطلاعات مفسر سیستمی فعلی، با تفکیک از طریق تمامی لایه‌های virtualenv.
پارامترها
cache (PyInfoCache | None https://docs.python.org/3/library/constants.html#None) -- کش متادیتای مفسر؛ زمانی که None باشد نتایج کش نمی‌شوند.
نوع بازگشتی
PythonInfo
سریال‌سازی اطلاعات این مفسر به یک رشته JSON.
دریافت اطلاعات پایتون برای مسیر یک فایل اجرایی مشخص.
پارامترها
نوع بازگشتی (Return type)
PythonInfo | None https://docs.python.org/3/library/constants.html#None
وا‌سری‌سازی اطلاعات مفسر از یک رشتهٔ JSON.
پارامترها (Parameters)
payload (str https://docs.python.org/3/library/stdtypes.html#str) -- رشتهٔ JSON تولیدشده توسط to_json().
نوع بازگشتی (Return type)
PythonInfo
پیمایش زنجیره‌های پیشوند virtualenv/venv جهت یافتن مفسر زیربنایی سیستم.
پارامترها (Parameters)
  • cache (PyInfoCache | None https://docs.python.org/3/library/constants.html#None) -- حافظهٔ پنهان فراداده‌های مفسر؛ در صورت None بودن، نتایج کَش نمی‌شوند.
  • target (PythonInfo) -- مفسری که باید شناسایی شود.
نوع بازگشتی (Return type)
PythonInfo
کشف یک فایل اجرایی منطبق پایتون در پوشهٔ prefix داده‌شده.
پارامترها (Parameters)
نوع بازگشتی (Return type)
PythonInfo

رابط داده‌های برنامه که توسط افزونه‌ها برای کَش‌سازی استفاده می‌شود.

رابط ذخیره‌سازی انتزاعی برای برنامه virtualenv.
پیش از خروج virtualenv فراخوانی می‌شود.
زمانی فراخوانی می‌شود که کاربر گزینه بازنشانی داده‌های برنامه (reset app data) را ارسال کند.
یک ذخیره‌ساز محتوا برای اطلاعات کَش‌شده مفسر در مسیر داده‌شده بازمی‌گرداند.
پارامترها
path (Path https://docs.python.org/3/library/pathlib.html#pathlib.Path) -- مسیر فایل اجرایی مفسر
نوع بازگشتی
ContentStore
بازمی‌گرداند
یک ذخیره‌ساز محتوا برای داده‌های کَش‌شده
تمام اطلاعات کَش‌شده مفسر را پاک می‌کند.
در صورتی که این ذخیره‌ساز داده‌های برنامه از به‌روزرسانی محتوای کَش‌شده پشتیبانی کند، برابر با True است.
یک ذخیره‌ساز محتوا برای گزارش به‌روزرسانی تعبیه‌شده (embed update log) یک توزیع بازمی‌گرداند.
پارامترها
نوع بازگشتی
ContentStore
بازمی‌گرداند
یک ذخیره‌ساز محتوا برای گزارش به‌روزرسانی
دایرکتوری ریشه ذخیره‌ساز داده‌های برنامه.
اگر این ذخیره‌ساز داده‌های برنامه گذرا (transient) باشد و بین دفعات اجرا پایدار نماند، برابر با True است.
مسیر مربوط به یک تصویر wheel کَش‌شده را بازمی‌گرداند.
پارامترها
نوع بازگشتی
Path https://docs.python.org/3/library/pathlib.html#pathlib.Path
بازمی‌گرداند
مسیر مربوط به wheel کَش‌شده
از در دسترس بودن یک مسیر روی دیسک اطمینان حاصل می‌کند و در صورت نیاز آن را از zipapp استخراج می‌نماید.
پارامترها
نوع بازگشتی
Generator https://docs.python.org/3/library/collections.abc.html#collections.abc.Generator[Path https://docs.python.org/3/library/pathlib.html#pathlib.Path]
بازمی‌گرداند
مسیر قابل استفاده روی دیسک را تولید می‌کند (yield)
یک مسیر را از zipapp به مکانی روی دیسک استخراج می‌کند.
پارامترها
نوع بازگشتی
Generator https://docs.python.org/3/library/collections.abc.html#collections.abc.Generator[Path https://docs.python.org/3/library/pathlib.html#pathlib.Path]
بازمی‌گرداند
مسیر استخراج‌شده را تولید می‌کند (yield)
یک قفل انحصاری روی مسیر داده‌شده به دست می‌آورد.

پلاگین‌های Creator ساختار دایرکتوری محیط مجازی را ایجاد کرده و مفسر Python را نصب می‌کنند.

کلاسی که با دریافت یک مفسر Python، یک محیط مجازی ایجاد می‌کند.
پارامترها
  • options (VirtualEnvOptions <#virtualenv.config.cli.parser.VirtualEnvOptions>)
  • interpreter (PythonInfo)

یک ایجادکنندهٔ محیط مجازی جدید می‌سازد.

پارامترها
  • options (VirtualEnvOptions <#virtualenv.config.cli.parser.VirtualEnvOptions>) -- گزینه‌های CLI تجزیه‌شده از add_parser_arguments()
  • interpreter (PythonInfo) -- مفسری که محیط مجازی از آن ایجاد می‌شود
تعیین می‌کند که آیا امکان ایجاد یک محیط مجازی وجود دارد یا خیر.
پارامترها
interpreter (PythonInfo) -- مفسر مورد نظر
نوع بازگشتی
CreatorMeta | bool https://docs.python.org/3/library/functions.html#bool | None https://docs.python.org/3/library/constants.html#None
بازمی‌گرداند
در صورتی که نتوان ایجاد کرد None، و در غیر این صورت هر شیء دیگری که به add_parser_arguments() ارسال خواهد شد
افزودن آرگومان‌های CLI برای ایجادکننده.
پارامترها
  • parser (ArgumentParser https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser) -- تجزیه‌کنندهٔ CLI
  • app_data (AppData) -- پوشهٔ داده‌های برنامه
  • interpreter (PythonInfo) -- مفسری که درخواست ایجاد محیط مجازی برای آن داده شده است
  • meta (CreatorMeta) -- مقدار بازگردانده‌شده توسط can_create()
نوع بازگشتی
None https://docs.python.org/3/library/constants.html#None
ایجاد محیط مجازی را انجام می‌دهد.
فایلی تولید می‌کند که نشان می‌دهد نباید از این مسیر نسخهٔ پشتیبان تهیه شود.
دستورالعمل‌های نادیده‌گرفتن (ignore) را برای سیستم‌های کنترل نسخه تولید می‌کند.

پلاگین‌های سیدر بسته‌های اولیه (مانند pip، setuptools، wheel) را درون محیط مجازی نصب می‌کنند.

یک سیدر برخی بسته‌های اولیه (seed) را درون یک محیط مجازی نصب خواهد کرد.
پارامترها

ایجاد.

پارامترها
  • options (VirtualEnvOptions <#virtualenv.config.cli.parser.VirtualEnvOptions>) -- گزینه‌های تجزیه‌شده همان‌طور که درون add_parser_arguments() تعریف شده‌اند
  • enabled (bool https://docs.python.org/3/library/functions.html#bool) -- پرچمی مبنی بر اینکه آیا سیدر فعال است یا خیر
توضیح می‌دهد که چرا این سیدر نمی‌تواند بسته‌های اولیه را برای مفسر مشخص‌شده نصب کند.
پارامترها
interpreter (PythonInfo) -- مفسری که محیط بر پایه آن بنا شده است
نوع بازگشتی
str https://docs.python.org/3/library/stdtypes.html#str | None https://docs.python.org/3/library/constants.html#None
مقادیر بازگشتی
در صورتی که سیدر از مفسر پشتیبانی کند مقدار None، در غیر این صورت پیامی که دلیل عدم امکان آن را شرح می‌دهد؛ فرایند گزینش، سیدری را که پیامی برگرداند رد کرده و آن را به کاربر نمایش می‌دهد
افزودن آرگومان‌های CLI برای این سازوکارهای سید (seed).
پارامترها
نوع بازگشتی
None https://docs.python.org/3/library/constants.html#None
انجام عملیات آماده‌سازی اولیه (seed).
پارامترها
creator (Creator) -- سازنده‌ای (بر پایه virtualenv.create.creator.Creator) که برای ساخت این محیط مجازی استفاده کرده‌ایم
نوع بازگشتی
None https://docs.python.org/3/library/constants.html#None

افزونه‌های فعال‌ساز اسکریپت‌های فعال‌سازی مختص هر شل را تولید می‌کنند.

اسکریپت فعال‌سازی را برای محیط مجازی تولید می‌کند.
پارامترها
options (VirtualEnvOptions <#virtualenv.config.cli.parser.VirtualEnvOptions>)

یک تولیدکننده فعال‌ساز جدید ایجاد می‌کند.

پارامترها
options (VirtualEnvOptions <#virtualenv.config.cli.parser.VirtualEnvOptions>) -- گزینه‌های تجزیه‌شده مطابق با تعریف در add_parser_arguments()
بررسی می‌کند که آیا اسکریپت فعال‌سازی در مفسر داده‌شده پشتیبانی می‌شود یا خیر.
پارامترها
interpreter (PythonInfo) -- مفسری که باید پشتیبانی شود
نوع بازگشتی
bool https://docs.python.org/3/library/functions.html#bool
مقادیر بازگشتی
در صورت پشتیبانی True، در غیر این صورت False
افزودن آرگومان‌های CLI برای این اسکریپت فعال‌سازی.
پارامترها
نوع بازگشتی
None https://docs.python.org/3/library/constants.html#None
تولید اسکریپت فعال‌سازی برای سازنده داده‌شده.
پارامترها
creator (Creator) -- سازنده‌ای (بر پایه virtualenv.create.creator.Creator) که برای ساخت این محیط مجازی استفاده شد
نوع بازگشتی
list https://docs.python.org/3/library/stdtypes.html#list[Path https://docs.python.org/3/library/pathlib.html#pathlib.Path]

این صفحه نحوه کارکرد درونی سیستم افزونه‌های virtualenv را توضیح می‌دهد.

ابزار virtualenv برای کشف افزونه‌ها از نقاط ورودی پایتون (setuptools / importlib.metadata) استفاده می‌کند. هر افزونه ذیل یکی از چهار گروه نقاط ورودی ثبت می‌شود:

  • virtualenv.discovery
  • virtualenv.create
  • virtualenv.seed
  • virtualenv.activate

هنگام راه‌اندازی، virtualenv تمام نقاط ورودی ثبت‌شده از این گروه‌ها را بارگذاری کرده و آن‌ها را به‌عنوان گزینه‌های CLI در دسترس قرار می‌دهد. پیاده‌سازی‌های داخلی در pyproject.toml خود virtualenv ثبت شده‌اند، در حالی که افزونه‌های شخص ثالث نقاط ورودی خود را در فراداده بسته خود ثبت می‌کنند.

هنگامی که یک بسته حاوی افزونه‌های virtualenv در همان محیط virtualenv نصب شود، افزونه‌ها بلافاصله و بدون نیاز به پیکربندی بیشتر در دسترس قرار می‌گیرند..SS "چرخه حیات افزونه (Plugin lifecycle)"

نمودار زیر نشان می‌دهد که افزونه‌ها چگونه شناسایی و اجرا می‌شوند: [نمودار]

این چرخه حیات مراحل زیر را دنبال می‌کند:

1.
دستور virtualenv شروع به کار کرده و تمام entry pointها را از چهار گروه افزونه شناسایی می‌کند
2.
تجزیه‌کننده خط فرمان (CLI parser) به‌صورت پویا ساخته می‌شود و گزینه‌های تمامی افزونه‌های شناسایی‌شده را در بر می‌گیرد
3.
آرگومان‌های کاربر برای انتخاب این‌که کدام افزونه‌های discovery، creator، seeder و activator استفاده شوند، تجزیه می‌شوند
4.
افزونه‌های انتخاب‌شده به ترتیب اجرا می‌شوند: discover → create → seed → activate
5.
هر مرحله خروجی خود را به مرحله بعدی ارسال می‌کند

هر نقطه گسترش از یک الگوی ثابت پیروی می‌کند:

کلاس پایه انتزاعی
هر نقطه گسترش یک کلاس پایه انتزاعی (Discover، Creator، Seeder، Activator) تعریف می‌کند که رابطی را که افزونه‌ها باید پیاده‌سازی کنند، مشخص می‌سازد.
پیاده‌سازی‌های توکار
نرم‌افزار virtualenv شامل پیاده‌سازی‌های توکاری است که به عنوان entry point در pyproject.toml خود آن ثبت شده‌اند. برای نمونه، سازنده توکار CPython به عنوان cpython3-posix ثبت شده است.
افزونه‌های شخص ثالث
بسته‌های خارجی رابط پایه را پیاده‌سازی کرده و entry pointهای خود را تحت همان گروه ثبت می‌کنند. پس از نصب، آن‌ها در کنار گزینه‌های توکار ظاهر می‌شوند.
گزینش در خط فرمان
پرچم‌های خط فرمان (--discovery، --creator، --seeder، --activators) به کاربران اجازه می‌دهند انتخاب کنند کدام پیاده‌سازی استفاده شود. چندین activator می‌توانند به‌طور هم‌زمان انتخاب شوند.
یکپارچه‌سازی با تجزیه‌کننده
هر افزونه می‌تواند از طریق متد کلاسی add_parser_arguments آرگومان‌های خط فرمان را اضافه کند. این آرگومان‌ها در virtualenv --help ظاهر می‌شوند و در صورت انتخاب افزونه، در دسترس خواهند بود.

افزونه‌ها در یک خط لوله (pipeline) اجرا می‌شوند که در آن هر مرحله به مرحله پیشین وابسته است:

افزونه discovery یک شیء PythonInfo ایجاد می‌کند که مفسر مبدأ Python را توصیف می‌نماید. این شیء حاوی فراداده‌هایی درباره نسخه Python، پلتفرم، مسیرها و قابلیت‌ها است. افزونه creator این PythonInfo را دریافت کرده و از آن برای تعیین نحوه ساخت ساختار محیط مجازی استفاده می‌کند.
افزونه creator یک شیء Creator ایجاد می‌کند که نشان‌دهنده محیط مجازی تازه‌ساخته‌شده است. این شیء شامل مسیرهای دایرکتوری bin محیط، site-packages و فایل اجرایی Python است. افزونه seeder از این مسیرها برای نصب بسته‌ها استفاده می‌کند.
پس از تکمیل عملیات بذرپاشی (seeding)، افزونه‌های activator از شیء Creator برای تولید اسکریپت‌های فعال‌سازی پوسته استفاده می‌کنند. این اسکریپت‌ها برای پیکربندی محیط پوسته، به دایرکتوری bin محیط و مسیرهای دیگر ارجاع می‌دهند.

این خط لوله تضمین می‌کند که هر افزونه اطلاعات لازم را از مراحل پیشین در اختیار دارد. شیء PythonInfo از discovery به creator منتقل می‌شود، و شیء Creator از creator هم به seeder و هم به activators فرستاده می‌شود.

افزونه‌های موجود در یک نقطه گسترش یکسان با یکدیگر تعاملی ندارند. در هر بار فراخوانی، تنها یک افزونه discovery و یک افزونه creator می‌توانند اجرا شوند، اگرچه چندین activator می‌توانند به‌طور هم‌زمان اجرا گردند. این جداسازی، افزونه‌ها را ساده و متمرکز بر وظیفه ویژه خود نگه می‌دارد.

پروژه virtualenv یک پروژه متن‌باز است که توسط داوطلبان نگهداری می‌شود و ما از هرگونه مشارکت استقبال می‌کنیم. بخش‌های زیر به شما کمک می‌کنند کار با توسعه، آزمایش و مستندسازی را آغاز کنید. بسیار خرسندیم که به کار روی virtualenv علاقه‌مندید. این سند برای آماده‌سازی شما جهت کار بر روی virtualenv و به عنوان یک راهنما و مرجع برای راه‌اندازی محیط توسعه نگاشته شده است. چنانچه در طول این فرایند با هرگونه مشکلی مواجه شدید، لطفاً در سامانه ردیابی مشکلات در https://github.com/pypa/virtualenv/issues/new?title=Trouble+with+development+environment یک issue درباره آن باز کنید.

نرم‌افزار virtualenv یک برنامه خط فرمانی است که با Python نوشته شده است. برای کار روی آن، به موارد زیر نیاز خواهید داشت:

•
کد منبع: در GitHub در دسترس است https://github.com/pypa/virtualenv. می‌توانید از git برای کلون کردن
مخزن استفاده کنید:
git clone https://github.com/pypa/virtualenv
cd virtualenv
  • مفسر Python: توصیه می‌کنیم از CPython استفاده کنید. می‌توانید از این راهنما https://realpython.com/installing-python برای راه‌اندازی آن استفاده نمایید.
  • ابزار tox https://pypi.org/project/tox: برای دریافت خودکار وابستگی‌های توسعه پروژه و اجرای مجموعه آزمون‌ها. توصیه می‌کنیم آن را با استفاده از pipx https://pipxproject.github.io/pipx نصب کنید.

    ساده‌ترین روش برای این کار، ایجاد محیط توسعهٔ tox و سپس فراخوانی virtualenv از درون پوشهٔ .tox/dev است.

tox -e dev
.tox/dev/bin/virtualenv  # on Linux
.tox/dev/Scripts/virtualenv  # on Windows

آزمون‌های virtualenv با استفاده از چارچوب آزمون pytest https://pypi.org/project/pytest نوشته شده‌اند. از tox https://pypi.org/project/tox برای خودکارسازی راه‌اندازی و اجرای آزمون‌های virtualenv استفاده می‌شود.

برای اجرای آزمون‌ها به‌صورت محلی دستور زیر را اجرا کنید:

tox -e py

این دستور مجموعه آزمون را برای همان نسخه از Python که tox تحت آن نصب شده است اجرا می‌کند. علاوه بر این می‌توانید با استفاده از قالب pyNN نسخهٔ خاصی از python را مشخص کنید، مانند: py314، pypy3 و غیره.

ابزار tox طوری پیکربندی شده است که هرگونه آرگومان اضافی را به pytest هدایت کند. این ویژگی امکان استفاده از رابط خط فرمان قدرتمند pytest https://docs.pytest.org/en/latest/usage.html#specifying-tests-selecting-tests را فراهم می‌کند. به عنوان مثال، می‌توانید آزمون‌ها را با استفاده از روش‌های متنوعی که pytest ارائه می‌دهد انتخاب کنید:

# Using markers
tox -e py -- -m "not slow"
# Using keywords
tox -e py -- -k "test_extra"

اجرای برخی از آزمون‌ها نیازمند وابستگی‌های بیشتری است، از جمله فعال‌سازهای پوسته‌های گوناگون (bash، fish، powershell و غیره). در صورت عدم وجود این وابستگی‌ها، آزمون‌های مربوطه به‌طور خودکار نادیده گرفته می‌شوند (skip می‌شوند)؛ با این حال توجه داشته باشید که در CI تمامی آزمون‌ها اجرا می‌گردند؛ بنابراین حتی اگر همهٔ آزمون‌ها به‌صورت محلی برای شما با موفقیت سپری شوند، ممکن است همچنان در CI با شکست مواجه شوند.

ابزار virtualenv از pre-commit https://pypi.org/project/pre-commit برای مدیریت بررسی ایستای پایه‌کد استفاده می‌کند. ابزار pre-commit بررسی‌های گوناگونی را روی تمامی فایل‌های موجود در virtualenv انجام می‌دهد و از ابزارهایی بهره می‌برد که به پیروی از یک شیوه‌نامهٔ کدنویسی یکپارچه در کل پایه‌کد کمک می‌کنند. برای استفاده از لینترها به‌صورت محلی، دستور زیر را اجرا کنید:

tox -e fix

نکته:

از به‌کاربردن کامنت‌های # noqa برای فرونشاندن هشدارهای لینتر خودداری کنید - تا جای ممکن، هشدارها باید برطرف شوند. کامنت‌های # noqa برای موارد نادری در نظر گرفته شده‌اند که سبک پیشنهادی باعث ایجاد مشکلات جدی در خوانایی کد می‌شود.

ابزار virtualenv یک نشانگر py.typed منطبق بر PEP 561 https://peps.python.org/pep-0561 ارائه می‌دهد و دارای نشانه‌گذاری‌های جامع نوع در سراسر پایه‌کد است. این بدان معناست که مصرف‌کنندگان پایین‌دستی و ابزارهای بررسی نوع به‌طور خودکار virtualenv را به‌عنوان یک بسته با نوع‌های درون‌خطی (inline-typed) شناسایی می‌کنند.

تمام کدهای جدید باید شامل نشانه‌گذاری‌های کامل نوع برای پارامترهای توابع و نوع‌های بازگشتی باشند. برای تأیید نشانه‌گذاری‌ها به‌صورت محلی، دستور زیر را اجرا کنید:

tox -e type

این دستور از ty https://docs.astral.sh/ty (بررسی‌کننده نوع مبتنی بر Rust از Astral) برای اعتبارسنجی نشانه‌گذاری‌ها در برابر Python 3.14 استفاده می‌کند. محیط دوم سازگاری را با حداقل نسخهٔ پشتیبانی‌شده بررسی می‌کند:

tox -e type-3.9

هر دو محیط اطمینان حاصل می‌کنند که نشانه‌گذاری‌ها سازگار و درست هستند..SS رهنمودهای حاشیه‌نویسی نوع (Annotation guidelines)

  • از from __future__ import annotations در بالای هر ماژول استفاده کنید (توسط تنظیمات required-imports در ruff الزامی شده است).
  • واردکردن‌هایی را که فقط برای بررسی نوع (type checking) نیاز هستند در داخل یک بلوک if TYPE_CHECKING: قرار دهید تا از سربار زمان اجرا جلوگیری شود.
  • قوانین ANN در ruff فعال هستند. قاعده ANN401 (typing.Any) به‌صورت موردی با یادداشت‌های درون‌خطی # noqa: ANN401 در مواردی که واقعاً به Any نیاز است (مانند serialization و dynamic dispatch) نادیده گرفته می‌شود.
  • انواع مشخص (concrete types) را بر Any ترجیح دهید. از Union / | برای پارامترهای تهی‌پذیر (nullable) یا چندنوعی استفاده کنید.
  • هنگامی که یک خطای نوع واقعاً غیرقابل رفع است (مانند محدودیت‌های کتابخانه‌های شخص ثالث)، آن را با یک یادداشت درون‌خطی # ty: ignore[rule-name] و یک توضیح توجیهی کوتاه نادیده بگیرید.

مستندات virtualenv با استفاده از Sphinx https://pypi.org/project/Sphinx ساخته می‌شود. این مستندات به زبان reStructuredText نوشته شده‌اند. برای ساخت محلی آن، اجرا کنید:

tox -e docs

مستندات ساخته‌شده را می‌توان در پوشه .tox/docs_out پیدا کرد و با باز کردن فایل index.html در آن پوشه مشاهده نمود.

دو فایل نشان‌واره در دایرکتوری docs/_static قرار دارند و نقش‌های متفاوتی ایفا می‌کنند، بنابراین هر دو عمداً نگه‌داری شده‌اند:

  • virtualenv.png نشان‌واره رسمی است — مارهای پیچیده‌شده دور یک ترمینال، به همراه علامت نوشتاری (wordmark). این فایل نشان‌واره وب‌سایت (light_logo/dark_logo در docs/conf.py) و فایلی است که در هر جا به نشان‌واره virtualenv نیاز باشد باید استفاده شود.
  • virtualenv.svg یک نشان ساده‌شده است که تنها به عنوان آیکون مرورگر یا favicon (html_favicon) استفاده می‌شود، چرا که نسخه پرجزئیات PNG در اندازه ۱۶×۱۶ ناخوانا خواهد بود. این یک نسخه برداری (vector) از فایل PNG نیست.

برنامه انتشار virtualenv به pip و setuptools وابسته است. ما آخرین نسخه این کتابخانه‌ها را بسته‌بندی می‌کنیم، بنابراین هر بار که نسخه جدیدی از هر یک از آن‌ها منتشر شود، اندکی پس از آن نسخه جدیدی از virtualenv منتشر خواهد شد (ما معمولاً چند روز صبر می‌کنیم تا از گنجاندن نسخه‌های معیوب احتمالی جلوگیری شود).

یک انتشار کامل، بسته را در PyPI https://pypi.org/project/virtualenv منتشر می‌کند، یک GitHub Release https://github.com/pypa/virtualenv/releases به همراه فایل zipapp پیوست‌شده ایجاد می‌کند، و get-virtualenv https://github.com/pypa/get-virtualenv را به‌روزرسانی می‌کند تا https://bootstrap.pypa.io/virtualenv.pyz نسخه جدید را ارائه دهد.

آرگومان --version در tox r -e release نسخه را کنترل می‌کند. مقدار پیش‌فرض آن auto است که دایرکتوری docs/changelog را بررسی می‌کند: اگر هرگونه قطعه‌فایل *.feature.rst یا *.removal.rst وجود داشته باشد، نسخه minor افزایش می‌یابد؛ در غیر این صورت نسخه patch افزایش می‌یابد. همچنین می‌توانید major، minor یا patch را به‌طور صریح ارسال کنید.

هر دو روش نتایج یکسانی ایجاد می‌کنند: یک کامیت انتشار و یک برچسب (tag) بر روی شاخه main. ارسال (push) تگ، گردش‌کار انتشار https://github.com/pypa/virtualenv/actions/workflows/release.yaml را آغاز می‌کند که بسته‌های sdist، wheel و zipapp را ساخته، از طریق trusted publisher در PyPI منتشر می‌کند، یک GitHub Release https://github.com/pypa/virtualenv/releases همراه با فایل zipapp پیوست‌شده می‌سازد، و get-virtualenv https://github.com/pypa/get-virtualenv را به‌روزرسانی می‌کند. اگر انتشار ناموفق باشد، یک کار بازگردانی (rollback job) به‌طور خودکار همه چیز را به حالت قبل بازمی‌گرداند.

از طریق GitHub Actions (توصیه‌شده)

1.
به Pre-release workflow https://github.com/pypa/virtualenv/actions/workflows/pre-release.yaml در GitHub بروید.
2.
روی Run workflow کلیک کرده و نوع افزایش نسخه را انتخاب نمایید (auto، major، minor یا patch).

به‌صورت محلی

tox r -e release

آرگومان --version <bump> را برای تغییر رفتار پیش‌فرض auto ارسال کنید (برای نمونه --version minor).

درخواست‌های ادغام (Pull Request) را برای شاخهٔ main ارسال کنید و شرح مناسبی از آنچه انجام می‌دهید و چرایی آن ارائه دهید. شما باید مجوز قانونی برای توزیع هر کدی که در virtualenv مشارکت می‌دهید داشته باشید و این کد باید تحت مجوز MIT License در دسترس باشد. آزمون‌هایی ارائه دهید که تغییرات شما را پوشش دهند و ابتدا آزمون‌ها را به‌صورت محلی اجرا کنید. virtualenv از چندین نسخهٔ Python و سیستم‌عامل مختلف پشتیبانی می‌کند <#compatibility-requirements>. هر pull request باید تمامی این پلتفرم‌ها را مد نظر قرار داده و روی همهٔ آن‌ها کار کند.

برای تسهیل فرایند بازبینی، Pull Requestها باید کوچک باشند. آن‌ها را خودبسنده و با دامنهٔ محدود نگه دارید. مطالعات نشان داده‌اند https://www.kessler.de/prd/smartbear/BestPracticesForPeerCodeReview.pdf که با افزایش اندازهٔ وصله (patch)، کیفیت بازبینی کاهش می‌یابد. گاهی این موضوع منجر به ایجاد چندین PR کوچک برای اعمال یک ویژگی بزرگ منفرد می‌شود. به‌ویژه، با pull requestها نباید مانند «شاخه‌های ویژگی» ("feature branches") که کارهای توسعه پیوسته در آن‌ها ادامه دارد برخورد شود. در عوض، ویژگی باید به بخش‌های کوچک‌تر و مستقل تفکیک شود تا بتوان آن‌ها را به‌صورت جداگانه بازبینی و ادغام کرد.

علاوه بر این، از گنجاندن تغییرات «ظاهری» ("cosmetic") در کدهای نامرتبط با تغییرات خود بپرهیزید، چرا که بازبینی PR را دشوارتر می‌کند. برای مثال می‌توان به بازچینی متن در یادداشت‌ها یا مستندات، یا افزودن و حذف خطوط خالی یا فاصله‌های خالی (whitespace) در خطوط اشاره کرد. در صورت نیاز، چنین تغییراتی می‌توانند جداگانه در قالب یک PR تحت عنوان «پاک‌سازی قالب‌بندی» ("formatting cleanup") ارسال شوند.

تمام pull requestها و ادغام‌ها در شاخهٔ 'main' با استفاده از GitHub Actions https://docs.github.com/en/actions (که توسط فایل .github/workflows/check.yaml در ریشهٔ مخزن پیکربندی شده است) آزمایش می‌شوند. می‌توانید وضعیت و نتایج اجراهای CI را برای PR خود در واسط کاربری وب GitHub برای pull request مشاهده کنید. همچنین در صورت شکست اجرای CI و تمایل به مشاهدهٔ خروجی، پیوندهایی به صفحات سرویس‌های CI برای ساخت‌های مشخص در قالب پیوندهای "Details" قرار دارند.

برای اجرای مجدد CI برای یک pull request، می‌توانید pull request را بسته و دوباره باز کنید یا تغییر دیگری به pull request ارسال نمایید. در صورت نیاز، نگه‌دارندگان پروژه می‌توانند شروع مجدد یک job/build را به‌صورت دستی فعال کنند.

فایل changelog.rst با استفاده از towncrier https://pypi.org/project/towncrier مدیریت می‌شود و تمام تغییرات غیربدیهی (non-trivial) باید همراه با یک مدخل خبری (news entry) باشند. برای افزودن یک مدخل به فایل اخبار، ابتدا باید یک issue ایجاد کرده باشید که تغییر مد نظرتان را شرح دهد. خود یک Pull Request ممکن است چنین کاربردی داشته باشد، اما ترجیح بر داشتن یک issue اختصاصی است (برای مثال، در صورتی که PR به دلایل مربوط به کیفیت کد رد شود).

هنگامی که یک issue یا pull request داشتید، شمارهٔ آن را برداشته و فایلی در داخل دایرکتوری docs/changelog به نام همان شماره با یکی از پسوندهای زیر ایجاد می‌کنید:

  • feature.rst,
  • bugfix.rst,
  • doc.rst,
  • removal.rst,
  • misc.rst.

بنابراین اگر شمارهٔ issue یا PR شما 1234 باشد و این تغییر یک باگ را برطرف کند، فایلی با نام docs/changelog/1234.bugfix.rst ایجاد خواهید کرد. PRها می‌توانند با ایجاد چند فایل، دسته‌بندی‌های متعددی را در بر بگیرند (به‌عنوان مثال، اگر هم‌زمان قابلیتی اضافه کرده و قابلیت قدیمی را منسوخ/حذف کرده‌اید، فایل‌های docs/changelog/1234.bugfix.rst و docs/changelog/1234.remove.rst را ایجاد می‌کنید). به همین ترتیب، اگر یک PR چند issue/PR را تحت تأثیر قرار دهد، می‌توانید برای هر کدام فایلی با محتوای یکسان بسازید و towncrier https://pypi.org/project/towncrier موارد تکراری را حذف خواهد کرد.

محتویات این فایل متنی با قالب‌بندی reStructuredText است که به‌عنوان محتوای مدخل فایل خبر استفاده خواهد شد. در اینجا نیازی به ارجاع به شماره‌های issue یا PR ندارید زیرا towncrier هنگام پردازش و رندر فایل خبر، به‌طور خودکار ارجاعی به تمامی issueهای مربوطه اضافه می‌کند.

برای حفظ هماهنگی سبک در فایل changelog.rst، ترجیح داده می‌شود مدخل خبری موجز و سرراست، با حروف‌چینی استاندارد جمله (sentence case)، کوتاه‌تر از ۱۲۰ نویسه و با لحن امری باشد -- یک مدخل باید جملهٔ This change will … را کامل کند. در موارد نادری که یک خط کافی نیست، از یک خط خلاصه با لحن امری استفاده کنید و با یک خط خالی آن را از شرح قابلیت/تغییر در یک یا چند بند که هر کدام حداکثر ۱۲۰ نویسه دارند جدا نمایید. به یاد داشته باشید که مدخل خبری برای کاربران نهایی است و تنها باید شامل جزئیات مرتبط با کاربر نهایی باشد.

تغییر جزئی (trivial) به هر تغییری گفته می‌شود که نیازمند ایجاد مدخل در فایل خبر نباشد. نمونه‌هایی از آن عبارتند از: بازآرایی کد (refactoring) بدون ایجاد تغییر از دید کاربران، اصلاح خطاهای نگارشی، اصلاح فاصله‌های خالی و غیره. برای نشانه‌گذاری یک PR به‌عنوان جزئی، مشارکت‌کننده تنها کافی است فایلی خالی با نام تصادفی و با پسوند .trivial در دایرکتوری news/ اضافه کند.

اگر می‌خواهید یک نگه‌دارندهٔ رسمی شوید، کار را با کمک کردن آغاز کنید. به‌عنوان نخستین گام، از بررسی و اولویت‌بندی (triage) اشکالات در ردیاب باگ‌های virtualenv استقبال می‌کنیم. نگه‌دارندگان virtualenv به مشارکت‌کنندگانی که مدتی در پروژه حضور داشته و مشارکت‌های مثبتی ارائه کرده‌اند، دسترسی‌های triage اعطا می‌کنند. این اقدام اختیاری است و برای تبدیل شدن به نگه‌دارندهٔ virtualenv بسیار توصیه می‌شود. سپس، هنگامی که احساس کردید آماده هستید، با یکی از نگه‌دارندگان ارتباط برقرار کنید تا رأی‌گیری میان نگه‌دارندگان فعلی را آغاز کنند.

نکته:

پس از تبدیل شدن به یک نگه‌دارنده، باید به فرد دسترسی به ابزارهای گوناگون مرتبط با virtualenv در پلتفرم‌های مختلف اعطا شود. این موارد جهت ارجاع بعدی نگه‌دارندگان در اینجا ذکر شده‌اند:
  • GitHub Push Access
  • PyPI Publishing Access
  • CI Administration capabilities
  • ReadTheDocs Administration capabilities

بدون تغییرات چشمگیر.

•
نبود یک منبع لازم برای هر دو حالت نصب، اکنون سازندهٔ توکار را از طریق meta.error غیرفعال می‌کند. این بررسی مقادیر RefWhen را با اعضای RefMust مقایسه می‌کرد، بنابراین فرآیند ایجاد با یک FileNotFoundError یا یک پیوند نمادینِ معلق (dangling symlink) شکست می‌خورد - توسط @darrenhuai https://github.com/darrenhuai. (#3227 https://github.com/pypa/virtualenv/issues/3227)

•
ارتقای حداقل نسخهٔ python-discovery به >=1.6 برای PythonInfo.system_exe، که مفسر سیستم را بدون تایپینگ مجاز به تهیِ system_executable گزارش می‌دهد - توسط @gaborbernat https://github.com/gaborbernat. (#3224 https://github.com/pypa/virtualenv/issues/3224)

•
مستندسازی نام‌هایی که مفسر درون یک محیط ایجادشده به آن‌ها پاسخ می‌دهد. صفحهٔ جدید ساختار محیط (Environment layout) <> آن‌ها را به تفکیک پلتفرم فهرست می‌کند، راهنماهای آموزشی و کاربری به آن اشاره دارند، و توضیحات سازنده‌ها پوشش می‌دهد که چرا یک محیط چندین نام را حمل می‌کند و چرا ویندوز یک بازهدایت‌کننده (redirector) را کپی می‌کند - توسط @gaborbernat https://github.com/gaborbernat. (#3225 https://github.com/pypa/virtualenv/issues/3225)

•
در ویندوز، virtualenv دیگر واسط (shim) مربوط به venvlauncher.exe در CPython 3.13+ را با نام خودِ واسط در Scripts کپی نمی‌کند، و میزبان‌هایی مانند python_d.exe نام مستعار خود را پس می‌گیرند. مجموعهٔ نام‌های مستعار، نام‌های خود را از واسطی که جانشین مفسر می‌شود می‌گرفت، بنابراین هر محیط یک نسخهٔ کپی ناخواسته از اجراکننده دریافت می‌کرد و نام فایل اصلیِ خود مفسر حذف می‌شد - توسط @darrenhuai https://github.com/darrenhuai. (#3223 https://github.com/pypa/virtualenv/issues/3223)

  • اصلاح بررسی نوع (type check) در برابر python-discovery نسخهٔ 1.5.2، که حاشیه‌نویسی‌های آن مقدار None را برای prefix و مقادیر عدد صحیح را برای sysconfig_vars مجاز می‌دانند: جایگزینی متغیرهای پیکربندی اکنون از پیشوند ناموجود صرف‌نظر می‌کند و مکان‌یابی libpython اشتراکی نیازمند مقادیر رشته‌ای برای INSTSONAME/LIBDIR است. (#3211 https://github.com/pypa/virtualenv/issues/3211)
  • متد ExePathRef.can_run اکنون بیت‌های اجرایی گروه و دیگران را به جای فقط بیت مالک بررسی می‌کند، و هنگامی که یک فایل هیچ‌یک از این سه را نداشته باشد، به جای None مقدار False برمی‌گرداند - توسط @darrenhuai https://github.com/darrenhuai. (#3217 https://github.com/pypa/virtualenv/issues/3217)
  • تابع safe_delete دیگر ignore_errors=True را به shutil.rmtree ارسال نمی‌کند، زیرا این کار گردانندهٔ chmod-and-retry خودش را با یک عملیات بی‌اثر (no-op) جایگزین می‌کرد و تمامی خطاها را نادیده می‌گرفت. فایل‌های فقط‌خواندنی - تمام فایل‌های درون ایمیج یک wheel، که توسط set_tree علامت‌گذاری می‌شوند - باقی می‌ماندند، بنابراین گزینه‌های --reset-app-data و --clear درخت‌هایی را که گزارش حذف آن‌ها را داده بودند دست‌نخورده نگه می‌داشتند. این گرداننده اکنون تنها خودِ عملیات حذف را مجدداً تلاش می‌کند، سایر بیت‌های حالت مجوز را حفظ می‌کند، و برای هر چیزی که نتواند پاک کند خطای اصلی را صادر می‌کند - توسط @darrenhuai https://github.com/darrenhuai. (#3222 https://github.com/pypa/virtualenv/issues/3222)

•
ارتقای wheelهای تعبیه‌شده:
•
بستهٔ setuptools به 84.0.0 از 83.0.0 (#3208 https://github.com/pypa/virtualenv/issues/3208)

•
متد ListType.split_values اکنون یک list بازمی‌گرداند که می‌توانید بیش از یک بار روی آن پیمایش کنید، و به جای صدور خطای TypeError ورودی از نوع bytes را می‌پذیرد - توسط @darrenhuai https://github.com/darrenhuai. (#3207 https://github.com/pypa/virtualenv/issues/3207)

•
ارتقای wheelهای تعبیه‌شده:
•
pip به 26.2.1 از 26.2 (#3206 https://github.com/pypa/virtualenv/issues/3206)

•
ارتقای wheelهای تعبیه‌شده:
•
pip به 26.2 از 26.1.2 (#u https://github.com/pypa/virtualenv/issues/u)

•
مستندسازی این که virtualenv.png نشان رسمی و virtualenv.svg نماد ساده‌شده صرفاً برای favicon است - توسط @gaborbernat https://github.com/gaborbernat. (#3199 https://github.com/pypa/virtualenv/issues/3199)

•
اعلام پشتیبانی از Python 3.15: فرآیند CI اکنون در برابر نسخه بتای CPython 3.15، از جمله ساختِ free-threaded 3.15t آزمایش می‌شود، و رده‌بند Programming Language :: Python :: 3.15 اعلان شده است. (#3192 https://github.com/pypa/virtualenv/issues/3192)

•
مقاوم‌سازی اعلان (prompt) فعال‌کننده fish در برابر توابع کاربری که دستورات توکار (builtins) را هم‌پوشانی (shadow) می‌کنند. هدایت functions، printf، string، echo و source/. از طریق builtin مانع از آن می‌شود که یک تابع هم‌پوشاننده (مانند ابزار ناوبری دایرکتوری به سبک نقطه که . را بازتعریف می‌کند) اعلان را برباید و وضعیت خروج (exit status) دستور قبلی را نادیده بگیرد؛ مطابق با رفع اشکال CPython در gh-140006 https://github.com/python/cpython/issues/140006. (#3185 https://github.com/pypa/virtualenv/issues/3185)

•
توقف نصب قلاب واردسازی distutils با نام _virtualenv.{py,pth} برای Python 3.10 و بالاتر، که در آن‌ها pip، setuptools و CPython از پیش کلیدهای پیکربندی نصبی را که این قلاب از آن‌ها محافظت می‌کرد نادیده می‌گیرند؛ این امر هزینه واردسازی این قلاب در زمان راه‌اندازی را حذف می‌کند. این قلاب همچنان برای Python 3.9 نصب می‌شود - #3181 https://github.com/pypa/virtualenv/issues/3181. (#3181 https://github.com/pypa/virtualenv/issues/3181)

•
ارتقای wheelهای تعبیه‌شده:
•
setuptools به 83.0.0 (#3180 https://github.com/pypa/virtualenv/issues/3180)

•
رد ایجاد محیط‌هایی که نسخه پایتون آن‌ها دیگر توسط wheelهای همراه پوشش داده نمی‌شود (در حال حاضر نسخه‌های پیش از 3.9). virtualenv پیش‌تر جدیدترین pip بسته‌بندی‌شده را جایگزین می‌کرد که روی چنین مقصدی قابل اجرا نبود و محیطی خراب به جا می‌گذاشت؛ اکنون سامانه انتخاب seeder آن را از همان ابتدا با خطایی واضح رد می‌کند. --no-seed و seederهای متفرقه شخص ثالث که wheelهای سازگار ارائه می‌دهند همچنان کار می‌کنند - توسط @gaborbernat https://github.com/gaborbernat. (#3171 https://github.com/pypa/virtualenv/issues/3171)

•
توقف پشتیبانی از Python 3.8؛ اکنون virtualenv برای اجرا و ساخت محیط‌ها به Python 3.9 یا بالاتر نیاز دارد. حذف بسته seed تعبیه‌شدهٔ wheel، که virtualenv آن را فقط برای Python 3.8 به همراه داشت. گزینه‌های --wheel و --no-wheel به عنوان گزینه‌های بی‌اثر (no-ops) باقی می‌مانند، اما اکنون هشدار می‌دهند که virtualenv آن‌ها را در نگارشی پس از 2026-12 حذف خواهد کرد - توسط @gaborbernat https://github.com/gaborbernat. (#3170 https://github.com/pypa/virtualenv/issues/3170)

•
ارتقای wheelهای تعبیه‌شده:

حذف wheel مربوط به نسخه 0.47.0 (#u https://github.com/pypa/virtualenv/issues/u)

•
ارتقای wheelهای تعبیه‌شده:
•
ارتقای pip به 26.1.2 از 26.1.1 (#u https://github.com/pypa/virtualenv/issues/u)
  • حل پیوندهای نمادین (symlink) مخصوص فایل اجرایی هنگام ثبت home و base-executable در pyvenv.cfg، مشابه با getpath.realpath در CPython (python/cpython#115237)، تا محیط‌های ایجادشده از روی یک پیوند نمادین به باینری مفسر بتوانند stdlib پایه را پیدا کنند (برای مثال python-build-standalone)؛ یک درخت مفسر با پیوند نمادین کامل دست‌نخورده باقی می‌ماند - توسط @gaborbernat https://github.com/gaborbernat. (#3157 https://github.com/pypa/virtualenv/issues/3157)
  • توقف export کردن PS1 از فعال‌ساز bash تا فرآیندهای فرزند وضعیت خط فرمان پوسته را به ارث نبرند. (#3158 https://github.com/pypa/virtualenv/issues/3158)
  • مدیریت تبدیل مسیرهای CYGWIN/MSYS/MINGW در اسکریپت فعال‌سازی fish - توسط user::LuNoX. (#3160 https://github.com/pypa/virtualenv/issues/3160)

•
جلوگیری از متوقف شدن deactivate در اسکریپت فعال‌سازی bash/zsh تحت set -e در صورت شکست hash -r (برای مثال هنگامی که hashing پوسته غیرفعال است) با افزودن || true، مشابه venv در CPython (gh-149701) و فراخوانی غیر-deactivate موجود - توسط @gaborbernat https://github.com/gaborbernat. (#3152 https://github.com/pypa/virtualenv/issues/3152)

•
رفع مشکلی که در آن جایگزینی venvlauncher_d.exe در ساخت خطایابی ویندوز هرگز اجرا نمی‌شد زیرا executables() نام فایل اجرایی مبدأ را به جای نام مقصد مقایسه می‌کرد، و رفع خطای AttributeError روی مشخصهٔ debug_build برای اشیاء اطلاعات مفسر که فاقد این فیلد بودند - توسط @gaborbernat https://github.com/gaborbernat. (#3151 https://github.com/pypa/virtualenv/issues/3151)

  • حذف کدهای مردهٔ مربوط به نسخه‌های پایتون پایین‌تر از محدودهٔ هدفِ پشتیبانی‌شده (PyPy 3.6، رابط‌های منسوخ‌شدهٔ importlib) و ساده‌سازی قلاب واردسازی زمان اجرا در _virtualenv.py - توسط @gaborbernat https://github.com/gaborbernat. (#3149 https://github.com/pypa/virtualenv/issues/3149)
  • پشتیبانی از ساخت‌های خطایابی ویندوز (python_d.exe، venvlauncher_d.exe) مطابق با رفتار venv در CPython، حذف جایگزینی مردهٔ __SCRIPT_DIR__ و محافظ نسخهٔ has_shim، حذف شاخهٔ غیرقابل‌دسترس Python 3.7 از pyvenv_launch_patch_active، و اصلاح پیام منسوخ شدن wheel به عبارت >= 3.9 - توسط @gaborbernat https://github.com/gaborbernat. (#3150 https://github.com/pypa/virtualenv/issues/3150)

•
شناسایی مفسرهای GraalPy با استفاده از نام نرمال‌شدهٔ GraalPy - توسط @timfel https://github.com/timfel. (#3144 https://github.com/pypa/virtualenv/issues/3144)

بدون تغییرات قابل توجه.

•
ارتقای wheelهای تعبیه‌شده:
•
ارتقای pip به 26.1.1 از 26.1 (#3138 https://github.com/pypa/virtualenv/issues/3138)

•
معرفی مجدد فعال‌ساز پوستهٔ xonsh (activate.xsh) که پیش‌تر در 20.7.0 حذف شده بود، و ترجیح دادن نقاط ورودی پیش‌فرض virtualenv توسط بارگذار افزونه‌ها به طوری که یک بستهٔ شخص ثالث نتواند با ثبت نام تکراری آن‌ها را بازنویسی کند. (#3003 https://github.com/pypa/virtualenv/issues/3003)

•
ارتقای wheelهای تعبیه‌شده:
•
ارتقای pip به 26.1 (#3132 https://github.com/pypa/virtualenv/issues/3132)

  • مقاوم‌سازی امنیتی: اعتبارسنجی هر مدخل در آرشیو seed wheel پیش از استخراج آن، تا یک wheel دست‌کاری‌شده نتواند از طریق مسیر مطلق یا پیمایش با .. از دایرکتوری تصویر app-data خارج شود. (#3118 https://github.com/pypa/virtualenv/issues/3118)
  • مقاوم‌سازی امنیتی: راستی‌آزمایی SHA-256 هر seed wheel بسته‌بندی‌شده هنگام بارگذاری آن، تا در صورت خراب یا دست‌کاری شدن فایل روی دیسک، به‌جای تحویل داده شدن به pip با خطای صریح متوقف شود. جدول درهم‌سازی (hash table) در کنار BUNDLE_SUPPORT توسط tasks/upgrade_wheels.py تولید می‌شود. (#3119 https://github.com/pypa/virtualenv/issues/3119)
  • مقاوم‌سازی امنیتی: اعتبارسنجی نام توزیع و مشخص‌کنندهٔ نسخهٔ ارسالی به pip download هنگام دریافت seed wheel، تا extras، پرچم‌های pip یا فرامنویسه‌های شل (shell metacharacters) نتوانند به خط فرمان subprocess تزریق شوند. (#3120 https://github.com/pypa/virtualenv/issues/3120)
  • مقاوم‌سازی امنیتی: جایگزینی بررسی اشتمال پیشوند رشته‌ای در virtualenv.util.zipapp با Path.relative_to تا توابع کمکی استخراج zipapp هر مسیری را که ذیل ریشهٔ آرشیو قرار نگیرد، رد کنند. (#3121 https://github.com/pypa/virtualenv/issues/3121)
  • مقاوم‌سازی امنیتی: عدم بازگشت خاموش به یک بافت (context) تأییدنشدهٔ HTTPS زمانی که درخواست دوره‌ای به‌روزرسانی به PyPI در راستی‌آزمایی TLS شکست می‌خورد. متادادهٔ بازگردانده‌شده مشخص می‌کند که virtualenv کدام نسخهٔ wheel را "به‌روز" تلقی کند، بنابراین پذیرش پاسخی تأییدنشده به مهاجم در سطح شبکه اجازه می‌دهد به‌روزرسانی‌های امنیتی را سرکوب کند. مقدار VIRTUALENV_PERIODIC_UPDATE_INSECURE=1 را برای بازگرداندن رفتار قبلی روی میزبان‌هایی با مخازن اعتماد (trust stores) خراب، تنظیم کنید. (#3122 https://github.com/pypa/virtualenv/issues/3122)

بدون تغییرات چشمگیر.

•
افزایش حداقل نسخهٔ python-discovery به >=1.2.2 جهت گنجاندن پشتیبانی از normalize_isa - توسط @rahuldevikar https://github.com/rahuldevikar. (#3117 https://github.com/pypa/virtualenv/issues/3117)

•
ارتقای wheelهای تعبیه‌شده:
•
ارتقای setuptools به 82.0.1 از 82.0.0 (#3093 https://github.com/pypa/virtualenv/issues/3093)
•
استفاده از عرض ترمینال برای قالب‌بندی پیام راهنما به‌جای مقدار ثابت ۲۴۰. (#3110 https://github.com/pypa/virtualenv/issues/3110)

•
به‌روزرسانی مولد wheelهای تعبیه‌شده (tasks/upgrade_wheels.py) جهت گنجاندن حاشیه‌نویسی‌های نوع (type annotations) در خروجی تولیدشده - توسط @rahuldevikar https://github.com/rahuldevikar. (#3075 https://github.com/pypa/virtualenv/issues/3075)

  • ارسال --without-scm-ignore-files به subprocess venv در Python 3.13+ تا ایجاد .gitignore در کنترل virtualenv باشد؛ که این امر رفتار ناپایدار در test_create_no_seed و نادیده گرفته شدن --no-vcs-ignore در مسیر subprocess را رفع می‌کند - توسط @gaborbernat https://github.com/gaborbernat. (#3089 https://github.com/pypa/virtualenv/issues/3089)
  • استفاده از BASH_SOURCE[0] به‌جای $0 در سازوکار جایگزین تغییر مکان اسکریپت فعال‌سازی bash، که مشکل مقدار نادرست PATH را هنگام source کردن اسکریپت فعال‌سازی از یک دایرکتوری دیگر برطرف می‌کند - توسط @gaborbernat https://github.com/gaborbernat. (#3090 https://github.com/pypa/virtualenv/issues/3090)

•
افزودن حاشیه‌نویسی‌های جامع نوع در سرتاسر کدبیس و ارائهٔ نشانگر PEP 561 py.typed تا مصرف‌کنندگان پایین‌دستی و بررسی‌کننده‌های نوع، virtualenv را به‌عنوان بسته‌ای با انواع درون‌خطی (inline-typed) شناسایی کنند - توسط @rahuldevikar https://github.com/rahuldevikar. (#3075 https://github.com/pypa/virtualenv/issues/3075)

•
منطق شناسایی پایتون (Python discovery) در قالب یک بستهٔ مستقل به نام python-discovery در PyPI استخراج شده است (مستندات در https://python-discovery.readthedocs.io) و اکنون به‌عنوان یک وابستگی استفاده می‌شود. اگر پیش‌تر بخش‌های داخلی discovery را مستقیماً وارد می‌کردید (مانند from virtualenv.discovery.py_info import PythonInfo)، آن را به from python_discovery import PythonInfo تغییر دهید. لایه‌های تطبیقی بازصادرکننده برای سازگاری با نسخه‌های پیشین در virtualenv.discovery.py_info، virtualenv.discovery.py_spec و virtualenv.discovery.cached_py_info ارائه شده‌اند، با این حال پشتیبانی‌نشده تلقی می‌شوند و ممکن است در نسخه‌های بعدی حذف شوند - توسط @gaborbernat https://github.com/gaborbernat. (#3070 https://github.com/pypa/virtualenv/issues/3070)

•
افزودن پشتیبانی از ایجاد محیط‌های مجازی با RustPython - توسط @elmjag https://github.com/elmjag. (#3010 https://github.com/pypa/virtualenv/issues/3010)

  • حل خودکار shimهای برنامه‌های مدیریت نسخه (pyenv، mise، asdf) به باینری واقعی Python در طول فرایند شناسایی، برای جلوگیری از انتخاب نادرست مفسر هنگامی که shimها در PATH هستند - توسط @gaborbernat https://github.com/gaborbernat. (#3049 https://github.com/pypa/virtualenv/issues/3049)
  • افزودن آگاهی از معماری (ISA) به فرایند شناسایی Python — کاربران اکنون می‌توانند یک پسوند معماری CPU در رشته مشخصات --python (مانند cpython3.12-64-arm64) تعیین کنند تا بین مفسرهایی با نسخه و تعداد بیت یکسان اما معماری‌های هدف متفاوت، تمایز قائل شوند. از sysconfig.get_platform() به عنوان منبع داده همراه با یکسان‌سازی چندسکویی (amd64 ↔ x86_64، aarch64 ↔ arm64) استفاده می‌کند. حذف این پسوند رفتار پیشین را حفظ می‌کند - توسط @rahuldevikar https://github.com/rahuldevikar. (#3059 https://github.com/pypa/virtualenv/issues/3059)

  • ذخیره داده‌های برنامه (حافظه‌های موقت pip/setuptools/wheel) در دایرکتوری کش سیستم‌عامل (platformdirs.user_cache_dir) به جای دایرکتوری داده‌ها (platformdirs.user_data_dir). داده‌های موجود برنامه در مکان قبلی، در نخستین استفاده به صورت خودکار منتقل می‌شوند. این امر تضمین می‌کند فایل‌های کش‌شده‌ای که امکان بارگیری مجدد دارند در محل استاندارد کش (مانند ~/.cache در لینوکس، ~/Library/Caches در macOS) قرار گیرند تا از فایل‌های پشتیبان مستثنی شده و توسط ابزارهای سیستم قابل پاک‌سازی باشند - توسط @rahuldevikar https://github.com/rahuldevikar. (#1884 https://github.com/pypa/virtualenv/issues/1884) (#1884 https://github.com/pypa/virtualenv/issues/1884)
  • افزودن پشتیبانی از متغیر محیطی PKG_CONFIG_PATH به تمامی اسکریپت‌های فعال‌سازی (Bash، Batch، PowerShell، Fish، C Shell، Nushell و Python). اکنون دایرکتوری lib/pkgconfig مربوط به virtualenv هنگام فعال‌سازی به طور خودکار به ابتدای PKG_CONFIG_PATH افزوده شده و هنگام غیرفعال‌سازی بازیابی می‌شود، که به بسته‌های استفاده‌کننده از pkg-config در حین ساخت/نصب امکان می‌دهد فایل‌های پیکربندی خود را پیدا کنند - توسط @rahuldevikar https://github.com/rahuldevikar. (#2637 https://github.com/pypa/virtualenv/issues/2637)
  • ارتقای pip تعبیه‌شده به 26.0.1 از 25.3 و setuptools به 82.0.0، 75.3.4 از 75.3.2، 80.9.0 - توسط @rahuldevikar https://github.com/rahuldevikar. (#3027 https://github.com/pypa/virtualenv/issues/3027)
  • جایگزینی کامنت‌های ty: ignore با باریک‌سازی مناسب نوع (type narrowing) با استفاده از assertionها و بررسی‌های صریح None - توسط @rahuldevikar https://github.com/rahuldevikar. (#3029 https://github.com/pypa/virtualenv/issues/3029)

  • جلوگیری از کپی شدن DLLهای pywin32 (pywintypes*.dll، pythoncom*.dll) در دایرکتوری Scripts هنگام ساخت virtualenv در Windows. این کار مشکلات سازگاری با pywin32 را برطرف می‌کند، چرا که انتظار دارد DLLهایش توسط اسکریپت پس از نصب اختصاصی خودش در site-packages/pywin32_system32 قرار گیرند - توسط @rahuldevikar https://github.com/rahuldevikar. (#2662 https://github.com/pypa/virtualenv/issues/2662)
  • حفظ پیوندهای نمادین (symlinks) در مسیرهای pyvenv.cfg برای تطابق با رفتار venv. استفاده از os.path.abspath() به جای os.path.realpath() جهت یکسان‌سازی مسیرها بدون حل کردن پیوندهای نمادین، که مشکلات مربوط به نصب‌های Python با دسترسی از طریق دایرکتوری‌های پیوند نمادین (رایج در سیستم‌های فایل متصل از طریق شبکه) را رفع می‌کند - توسط @rahuldevikar https://github.com/rahuldevikar. رفع اشکال #2770 https://github.com/pypa/virtualenv/issues/2770. (#2770 https://github.com/pypa/virtualenv/issues/2770)
  • اصلاح اسکریپت‌های فعال‌سازی Windows جهت قرار دادن صحیح مسیر python.exe در علامت نقل‌قول (کوتیشن)، برای جلوگیری از خرابی در مواردی که Python در مسیری دارای فاصله (مانند C:\Program Files) نصب شده و فایلی به نام C:\Program روی سیستم‌فایل وجود دارد - توسط @rahuldevikar https://github.com/rahuldevikar. (#2985 https://github.com/pypa/virtualenv/issues/2985)
  • اصلاح سازگاری با bash -u (set -o nounset) در اسکریپت فعال‌سازی bash با بهره‌گیری از ${PKG_CONFIG_PATH:-} و ${PKG_CONFIG_PATH:+:${PKG_CONFIG_PATH}} جهت مدیریت PKG_CONFIG_PATH تعریف‌نشده - توسط @Fridayai700 https://github.com/Fridayai700. (#3044 https://github.com/pypa/virtualenv/issues/3044)
  • مدیریت مناسب کش معیوب روی دیسک و JSON نامعتبر حاصل از زیرفرایند بازجویی Python به جای توقف ناگهانی برنامه با خطاهای مدیریت‌نشدهٔ JSONDecodeError یا KeyError - توسط @gaborbernat https://github.com/gaborbernat. (#3054 https://github.com/pypa/virtualenv/issues/3054)

•
رفع آسیب‌پذیری‌های TOCTOU در هنگام ساخت app_data و دایرکتوری قفل که می‌توانست از طریق حملات پیوند نمادین (symlink) مورد سوءاستفاده قرار گیرد - گزارش شده توسط @tsigouris007 https://github.com/tsigouris007، رفع شده توسط @gaborbernat https://github.com/gaborbernat. (#3013 https://github.com/pypa/virtualenv/issues/3013)

•
افزودن پشتیبانی از مشخص‌کننده‌های نسخه طبق PEP 440 در گزینه --python. کاربران اکنون می‌توانند با عملگرهایی مانند >=، <=، ~= و غیره نسخه‌های Python را مشخص کنند. برای مثال: virtualenv --python=">=3.12" myenv . (:issue:`2994)

  • رفع وضعیت رقابتی (race condition) در _virtualenv.py هنگام رونویسی فایل حین ایمپورت، که از بروز NameError هنگام دسترسی به _DISTUTILS_PATCH جلوگیری می‌کند - توسط @gracetyy https://github.com/gracetyy. (#2969 https://github.com/pypa/virtualenv/issues/2969)
  • ارتقای wheelهای تعبیه‌شده:
•
pip به 25.3 از 25.2 (#2989 https://github.com/pypa/virtualenv/issues/2989)

•
پذیرش RuntimeError در test_too_many_open_files، توسط @esafak https://github.com/esafak (#2935 https://github.com/pypa/virtualenv/issues/2935)

•
بازگردانی تغییرات مربوط به استخراج ماژول discovery - توسط @gaborbernat https://github.com/gaborbernat. (#2978 https://github.com/pypa/virtualenv/issues/2978)

•
افزودن پشتیبانی از Tcl و Tkinter. خواهش می‌کنم! با مشارکت @esafak https://github.com/esafak. (#425 https://github.com/pypa/virtualenv/issues/425)

بدون تغییرات قابل توجه.

•
ارتقای wheelهای تعبیه‌شده:

•
عدم بسته‌بندی wheelهای wheel (به‌جز در Python 3.8)؛ setuptools شامل پشتیبانی بومی از bdist_wheel است. به‌روزرسانی pip به 25.1. (#2868 https://github.com/pypa/virtualenv/issues/2868)

•
افزودن پشتیبانی از GraalPy https://github.com/oracle/graalpython. (#2832 https://github.com/pypa/virtualenv/issues/2832)

•
ارتقای wheelهای تعبیه‌شده:
•
setuptools به 78.1.0 از 75.3.2 (#2863 https://github.com/pypa/virtualenv/issues/2863)

•
نادیده‌گرفتن دایرکتوری‌های غیرقابل خواندن در PATH. (#2794 https://github.com/pypa/virtualenv/issues/2794)

•
رفع هشدارهای ناسازگاری حافظهٔ پنهان PyInfo - توسط @robsdedude https://github.com/robsdedude. (#2827 https://github.com/pypa/virtualenv/issues/2827)

•
افزودن پشتیبانی از انتخاب مفسرهای پایتون free-threaded، مانند python3.13t. (#2809 https://github.com/pypa/virtualenv/issues/2809)

•
ارتقای wheelهای تعبیه‌شده:
•
setuptools از 75.6.0 به 75.8.0 (#2823 https://github.com/pypa/virtualenv/issues/2823)

•
صرف‌نظر از آزمون‌های tcsh در نسخه‌های خراب tcsh - توسط @gaborbernat https://github.com/gaborbernat. (#2814 https://github.com/pypa/virtualenv/issues/2814)

•
نوشتن فایل CACHEDIR.TAG در زمان ایجاد - توسط "user:neilramsay. (#2803 https://github.com/pypa/virtualenv/issues/2803)

•
ارتقای wheelهای تعبیه‌شده:
•
setuptools از 75.2.0 به 75.3.0 (#2798 https://github.com/pypa/virtualenv/issues/2798)
•
ارتقای wheelهای تعبیه‌شده:

•
ارتقای wheelهای تعبیه‌شده:
•
pip از 24.2 به 24.3.1 (#2789 https://github.com/pypa/virtualenv/issues/2789)

•
توقف پشتیبانی از 3.7 زیرا محیط‌های CI دیگر اجازه اجرای آن را نمی‌دهند - توسط @gaborbernat https://github.com/gaborbernat. (#2758 https://github.com/pypa/virtualenv/issues/2758)

•
رفع خرابی zipapp در ویندوز پس از نسخه 0.3.9 از distlib - توسط @gaborbernat https://github.com/gaborbernat. (#2784 https://github.com/pypa/virtualenv/issues/2784)

•
کوتیشن‌گذاری مناسب جانگهدارنده‌های رشته در قالب‌های اسکریپت فعال‌سازی جهت کاهش خطر تزریق احتمالی دستور - توسط @y5c4l3 https://github.com/y5c4l3. (#2768 https://github.com/pypa/virtualenv/issues/2768)

•
ارتقای wheelهای تعبیه‌شده: setuptools به 75.1.0 از 74.1.2 - توسط @gaborbernat https://github.com/gaborbernat. (#2765 https://github.com/pypa/virtualenv/issues/2765)

•
ارتقای wheelهای تعبیه‌شده:

•
رفع مشکل شناسایی Python مبتنی بر PATH در Windows - توسط @ofek https://github.com/ofek. (#2712 https://github.com/pypa/virtualenv/issues/2712)

•
امکان شناسایی مفسرهای خاص (مانند python3.12) توسط قابلیت شناسایی توکار (builtin discovery) هنگام ارائه یک مشخصه عمومی (مانند python3) - توسط @flying-sheep https://github.com/flying-sheep. (#2709 https://github.com/pypa/virtualenv/issues/2709)

•
تغییر نام pathmod به parser در Python 3.13.0a6. (#2702 https://github.com/pypa/virtualenv/issues/2702)

•
ارتقای wheelهای تعبیه‌شده:

•
ارتقای wheelهای توکار:
•
ارتقای wheelهای توکار:

•
اکنون آزمون‌ها در CI با Python 3.13.0a2 پاس می‌شوند - توسط @hroncok https://github.com/hroncok. (#2673 https://github.com/pypa/virtualenv/issues/2673)

•
ارتقای wheelهای توکار:
•
wheel از 0.41.2 به 0.41.3 (#2665 https://github.com/pypa/virtualenv/issues/2665)
•
ارتقای wheelهای توکار:

•
setuptools از 68.1.2 به 68.2.0 (#2642 https://github.com/pypa/virtualenv/issues/2642)

•
ارتقای wheelهای توکار:

  • رفع ResourceWarning هنگام خروج ناشی از زیرپردازش به‌روزرسانی دوره‌ای (#2472 https://github.com/pypa/virtualenv/issues/2472)
  • ارتقای بسته‌های wheel تعبیه‌شده:
•
wheel از 0.41.0 به 0.41.1 (#2622 https://github.com/pypa/virtualenv/issues/2622)

•
ارتقای بسته‌های wheel تعبیه‌شده:

•
ارتقای بسته‌های wheel تعبیه‌شده:
•
pip از 23.1.2 به 23.2 - توسط @arielkirkwood https://github.com/arielkirkwood (#2611 https://github.com/pypa/virtualenv/issues/2611)

•
صدور پیشوند اعلان (prompt prefix) به عنوان VIRTUAL_ENV_PROMPT هنگام فعال‌سازی یک محیط مجازی - توسط @jimporter https://github.com/jimporter. (#2194 https://github.com/pypa/virtualenv/issues/2194)

•
setuptools از 67.8.0 به 68.0.0 (#2607 https://github.com/pypa/virtualenv/issues/2607)

  • به‌روزرسانی و ساده‌سازی اسکریپت فعال‌سازی nushell، رفع مشکلی در Windows که منجر به خطاهای متوالی command not found می‌شد - توسط @melMass https://github.com/melMass. (#2572 https://github.com/pypa/virtualenv/issues/2572)
  • ارتقای بسته‌های wheel تعبیه‌شده:
•
setuptools از 67.7.2 به 67.8.0 (#2588 https://github.com/pypa/virtualenv/issues/2588)

•
عدم نصب بسته‌های آغازین (seed) wheel و setuptools برای Python 3.12+. برای بازگرداندن رفتار قبلی از موارد زیر استفاده کنید:
  • برای wheel از متغیر محیطی VIRTUALENV_WHEEL=bundle یا گزینه خط فرمان --wheel=bundle استفاده کنید،
  • برای setuptools از متغیر محیطی VIRTUALENV_SETUPTOOLS=bundle یا گزینه خط فرمان --setuptools=bundle استفاده کنید.

توسط @chrysle https://github.com/chrysle. (#2487 https://github.com/pypa/virtualenv/issues/2487)

•
پشتیبانی از 3.12 - توسط @gaborbernat https://github.com/gaborbernat. (#2558 https://github.com/pypa/virtualenv/issues/2558)

•
حذف پشتیبانی از ساخت مفسرهای Python <=3.6 (شامل ۲). حذف pip نسخه‌های 20.3.4 و 21.3.1؛ wheel نسخه 0.37.1؛ setuptools نسخه‌های 59.6.0، 44.1.1 و 50.3.2 - توسط @gaborbernat https://github.com/gaborbernat. (#2548 https://github.com/pypa/virtualenv/issues/2548)

•
آغاز صریح ساختار دستوری closure با {||. (#2512 https://github.com/pypa/virtualenv/issues/2512)

•
تغییر بررسی وجود متغیر محیطی در اسکریپت فعال‌سازی Nushell به‌منظور عدم استفاده از دستور منسوخ‌شده. (#2506 https://github.com/pypa/virtualenv/issues/2506)

•
پشتیبانی از نسخه 3 بسته platformdirs - توسط @cdce8p https://github.com/cdce8p. (#2499 https://github.com/pypa/virtualenv/issues/2499)

•
حذف پشتیبانی از محیط زمان اجرای 3.6 (همچنان امکان ساخت 2.7+ وجود دارد) - توسط @gaborbernat https://github.com/gaborbernat. (#2489 https://github.com/pypa/virtualenv/issues/2489)

•
حذف واسط‌های (shim) غیرضروری برای ساختار دایرکتوری PyPy3 (#2426 https://github.com/pypa/virtualenv/issues/2426)

•
عدم خاموش کردن echo برای دستورهای پسین در اسکریپت‌های فعال‌ساز دسته‌ای (activate.bat و deactivate.bat) - توسط @pawelszramowski https://github.com/pawelszramowski. (#2411 https://github.com/pypa/virtualenv/issues/2411)

•
ارتقای setuptools تعبیه‌شده به 65.3 - توسط @gaborbernat https://github.com/gaborbernat. (#2405 https://github.com/pypa/virtualenv/issues/2405)

•
ارتقای pip تعبیه‌شده به 22.2.2 از 22.2.1 و setuptools به 63.4.1 از 63.2.0 - توسط @gaborbernat https://github.com/gaborbernat. (#2395 https://github.com/pypa/virtualenv/issues/2395)

•
ارتقای pip جاسازی‌شده از 22.2 به 22.2.1 - توسط @gaborbernat https://github.com/gaborbernat. (#2391 https://github.com/pypa/virtualenv/issues/2391)

•
به‌روزرسانی اسکریپت‌های فعال‌سازی Nushell به نسخهٔ 0.67 - توسط @kubouch https://github.com/kubouch. (#2386 https://github.com/pypa/virtualenv/issues/2386)

•
پشتیبانی از بستهٔ پایتون تعبیه‌پذیر در ویندوز (Windows embeddable Python package): گنجاندن python<VERSION>.zip در منابع سازنده - توسط @reksarka https://github.com/reksarka. (#1774 https://github.com/pypa/virtualenv/issues/1774)

•
پشتیبانی از ایجاد یک محیط مجازی از چارچوب Python 2.7 در macOS 12 - توسط @nickhutchinson https://github.com/nickhutchinson. (#2284 https://github.com/pypa/virtualenv/issues/2284)

•
ارتقای setuptools جاسازی‌شده به 62.1.0 از 61.0.0 - توسط @gaborbernat https://github.com/gaborbernat. (#2327 https://github.com/pypa/virtualenv/issues/2327)

•
پشتیبانی از اسکریپت‌های فعال‌سازی Nushell با نسخهٔ nu 0.60 - توسط @kubouch https://github.com/kubouch. (#2321 https://github.com/pypa/virtualenv/issues/2321)

•
ارتقای setuptools جاسازی‌شده به 61.0.0 از 60.10.0 - توسط @gaborbernat https://github.com/gaborbernat. (#2322 https://github.com/pypa/virtualenv/issues/2322)

•
ارتقای setuptools تعبیه‌شده از 60.6.0 به 60.9.3 - توسط @gaborbernat https://github.com/gaborbernat. (#2306 https://github.com/pypa/virtualenv/issues/2306)

•
افزودن اطلاعات wheel دانلودشده به فایل JSON تعبیه‌شده مربوطه جهت جلوگیری از دانلود مجدد همان wheel. - توسط @mayeut https://github.com/mayeut. (#2268 https://github.com/pypa/virtualenv/issues/2268)

•
امضای فایل اجرایی python2 روی Darwin arm64 - توسط @tmspicer https://github.com/tmspicer. (#2233 https://github.com/pypa/virtualenv/issues/2233)

•
رفع مشکل نصب نسخه‌های تثبیت‌شده (pinned) از pip، setuptools و wheel - توسط @mayeut https://github.com/mayeut. (#2203 https://github.com/pypa/virtualenv/issues/2203)

•
ارتقای setuptools تعبیه‌شده از 60.1.0 به 60.1.1 - توسط @gaborbernat https://github.com/gaborbernat. (#2258 https://github.com/pypa/virtualenv/issues/2258)

  • اگر یک طرح نصب "venv" در sysconfig وجود داشته باشد، virtualenv اکنون از آن برای ایجاد محیط‌های مجازی جدید استفاده می‌کند. این به توزیع‌کنندگان Python، مانند Fedora، اجازه می‌دهد تا طرح نصب پیش‌فرض را بدون تأثیر بر مسیرها در محیط‌های مجازی جدید وصله/جایگزین کنند. روش مشابهی برای Python و ماژول venv پیشنهاد شده بود https://bugs.python.org/issue45413 - توسط hroncok (#2208 https://github.com/pypa/virtualenv/issues/2208)
  • اعلان (پرامپت) فعال‌شدهٔ virtualenv اکنون همیشه در پرانتز قرار می‌گیرد. این امر بر محیط‌های مجازی ایجادشده با مشخصهٔ --prompt تأثیر می‌گذارد و رفتار virtualenv را با venv همگام و هم‌تراز می‌کند. (#2224 https://github.com/pypa/virtualenv/issues/2224)

•
رفع پرامپت خراب تنظیم‌شده توسط activate.bat - توسط @SiggyBar https://github.com/SiggyBar. (#2225 https://github.com/pypa/virtualenv/issues/2225)

  • ارتقای setuptools تعبیه‌شده از 57.4.0 به 58.0.4 و pip از 21.2.3 به 21.2.4
  • افزودن اسکریپت فعال‌سازی برای nushell

•
ارتقای pip تعبیه‌شده از 21.2.2 به 21.2.3 و wheel از 0.36.2 به 0.37.0 - توسط @gaborbernat https://github.com/gaborbernat. (#2168 https://github.com/pypa/virtualenv/issues/2168)

•
رفع مشکل باز کردن آیتم‌های دیکشنری در PythonInfo.install_path (#2165 https://github.com/pypa/virtualenv/issues/2165)

•
ارتقای pip تعبیه‌شده از 21.1.3 به 21.2.2 و setuptools از 57.1.0 به 57.4.0 - توسط @gaborbernat https://github.com/gaborbernat (#2159 https://github.com/pypa/virtualenv/issues/2159)

•
حذف فعال‌کنندهٔ (activator) xonsh به دلیل خرابی مکرر در CI و عدم پشتیبانی از سوی نگه‌دارندگان این بسته‌ها؛ به بالادست توصیه می‌شود پشتیبانی از پروژه را به صورت یک پلاگین ادامه دهد https://github.com/xonsh/xonsh/issues/3689 - توسط @gaborbernat https://github.com/gaborbernat. (#2160 https://github.com/pypa/virtualenv/issues/2160)

•
پشتیبانی از مفسرهای Python بدون distutils (در این موارد به عنوان جایگزین از syconfig استفاده می‌شود) - توسط @gaborbernat https://github.com/gaborbernat. (#1910 https://github.com/pypa/virtualenv/issues/1910)

•
ارتقای pip توکار به 21.1.3 و setuptools به 57.1.0 - توسط @gaborbernat https://github.com/gaborbernat. (#2135 https://github.com/pypa/virtualenv/issues/2135)

•
حذف پشتیبانی از python 3.4 به دلیل گذشت بیش از ۲ سال از EOL - توسط @gaborbernat https://github.com/gaborbernat. (#2141 https://github.com/pypa/virtualenv/issues/2141)

•
ارتقای pip توکار به 21.1.2 و setuptools به 57.0.0 - توسط @gaborbernat https://github.com/gaborbernat. (#2123 https://github.com/pypa/virtualenv/issues/2123)

•
رفع خرابی site.getsitepackages() در python2 روی debian - توسط @freundTech https://github.com/freundTech. (#2105 https://github.com/pypa/virtualenv/issues/2105)

•
رفع مشکل از کار افتادن هنگام اجرای virtualenv با --upgrade-embed-wheels - توسط @gaborbernat https://github.com/gaborbernat. (#2058 https://github.com/pypa/virtualenv/issues/2058)

•
ارتقای بسته‌های توکار pip و setuptools به آخرین نسخه‌های پشتیبانی‌شده در بالادست (21.0.1 و 52.0.0) - توسط @gaborbernat https://github.com/gaborbernat. (#2060 https://github.com/pypa/virtualenv/issues/2060)

•
امکان ارسال دیکشنری متغیرهای محیطی برای استفاده در API برنامه‌نویسی، با مقدار پیش‌فرض os.environ در صورت عدم تعیین - توسط @gaborbernat https://github.com/gaborbernat. (#2054 https://github.com/pypa/virtualenv/issues/2054)
•
ارتقای setuptools تعبیه‌شده به 51.3.3 از 51.1.2 - توسط @gaborbernat https://github.com/gaborbernat. (#2055 https://github.com/pypa/virtualenv/issues/2055)

  • ارتقای pip تعبیه‌شده به 20.3.3، setuptools به 51.1.1 و wheel به 0.36.2 - توسط @gaborbernat https://github.com/gaborbernat. (#2036 https://github.com/pypa/virtualenv/issues/2036)
  • اجازه دادن به شکست بدون خطای لغو تعریف تابع (unfunctioning) برای pydoc تا virtualenvها بتوانند تحت Zsh با set -e فعال شوند (زیرا در غیر این صورت، چنانچه تابع در Zsh وجود نداشته باشد، دستورات unset -f و unfunction با کد ۱ خارج می‌شوند) - توسط @d125q https://github.com/d125q. (#2049 https://github.com/pypa/virtualenv/issues/2049)
  • دور ریختن اطلاعات کش‌شدهٔ python در صورتی که فایل اجرایی سیستم دیگر وجود نداشته باشد (برای مثال زمانی که فایل اجرایی یک shim است و فایل اجرایی نگاشت‌شده جایگزین شده باشد - مانند موردی که در pyenv رخ می‌دهد) - توسط @gaborbernat https://github.com/gaborbernat. (#2050 https://github.com/pypa/virtualenv/issues/2050)

•
سازوکار شناسایی توکار اکنون یک آرگومان --try-first-with می‌پذیرد و ابتدا این موارد به عنوان مفسرهای معتبر آزموده می‌شوند. می‌توان از این گزینه برای تحمیل شناسایی یک فایل اجرایی مشخص python در مواقعی که ترتیب یا سازوکار شناسایی با خطا مواجه می‌شود استفاده کرد - توسط @gaborbernat https://github.com/gaborbernat. (#2046 https://github.com/pypa/virtualenv/issues/2046)

  • در توزیع‌های python 3.7+ در ویندوز که در آن‌ها shim فایل exe وجود ندارد، بازگشت به روش‌های قدیمی صورت می‌گیرد - توسط @gaborbernat https://github.com/gaborbernat. (#1986 https://github.com/pypa/virtualenv/issues/1986)
  • هنگام شناسایی مفسرها در ویندوز از طریق PEP-514، انتشار‌های PythonCore نسبت به سایر موارد ترجیح داده می‌شوند. virtualenv بیشتر از طریق pip با این توزیع به کار می‌رود، بنابراین نسبت به سایرین مانند conda در اولویت قرار می‌گیرد - توسط @gaborbernat https://github.com/gaborbernat. (#2046 https://github.com/pypa/virtualenv/issues/2046)

•
ارتقای pip به 20.3.1، setuptools به 51.0.0 و wheel به 0.36.1 - توسط @gaborbernat https://github.com/gaborbernat. (#2029 https://github.com/pypa/virtualenv/issues/2029)

تغییرات چشمگیری وجود ندارد.

  • امکان چشم‌پوشی اختیاری از دستور ignore مربوط به VCS برای کل دایرکتوری virtualenv، با استفاده از گزینهٔ no-vcs-ignore <#no-vcs-ignore>، که به‌طور پیش‌فرض False است. (#2003 https://github.com/pypa/virtualenv/issues/2003)
  • افزودن گزینهٔ --read-only-app-data جهت اجازه برای ساخت بر پایهٔ یک کش موجود از app data که غیرقابل نوشتن است. این مورد ممکن است (برای مثال) جهت تولید یک ایمیج docker که در آن app-data از پیش پر شده است، مفید باشد.
ENV \
    VIRTUALENV_OVERRIDE_APP_DATA=/opt/virtualenv/cache \
    VIRTUALENV_SYMLINK_APP_DATA=1
RUN virtualenv venv && rm -rf venv
ENV VIRTUALENV_READ_ONLY_APP_DATA=1
USER nobody
# this virtualenv has symlinks into the read-only app-data cache
RUN virtualenv /tmp/venv

پچ از @asottile https://github.com/asottile. (#2009 https://github.com/pypa/virtualenv/issues/2009)

•
اصلاح پردازش متغیر محیطی VIRTUALENV_PYTHON و چندمقداری کردن آن (جداشده با کاما) - توسط @pneff https://github.com/pneff. (#1998 https://github.com/pypa/virtualenv/issues/1998)

•
مشخصهٔ python اکنون می‌تواند یک یا چند مقدار بپذیرد؛ نخستین مورد یافت‌شده برای ساخت محیط مجازی استفاده می‌شود - توسط @gaborbernat https://github.com/gaborbernat. (#1995 https://github.com/pypa/virtualenv/issues/1995)

•
ارتقای pip تعبیه‌شده به 20.2.1، setuptools به 49.6.0 و wheel به 0.35.1 - توسط @gaborbernat https://github.com/gaborbernat. (#1918 https://github.com/pypa/virtualenv/issues/1918)

•
ارتقای pip به 20.2.1 و setuptools به 49.2.1 - توسط @gaborbernat https://github.com/gaborbernat. (#1915 https://github.com/pypa/virtualenv/issues/1915)

•
ارتقای pip تعبیه‌شده از نسخه 20.1.2 به 20.2 - توسط @gaborbernat https://github.com/gaborbernat. (#1909 https://github.com/pypa/virtualenv/issues/1909)

  • خروجی گزارش‌گیری بهتر هنگام اجرا و فعال‌سازی گزارش‌گیری در فراخوانی فرایند پس‌زمینه (از _VIRTUALENV_PERIODIC_UPDATE_INLINE می‌توان برای اشکال‌زدایی درون‌خطی رفتار استفاده کرد)
  • استفاده از بافت تاییدنشده (unverified context) به‌عنوان جایگزین هنگام استعلام تاریخ انتشار از PyPi،
  • توقف بارگیری wheelها به محض رسیدن به نسخه تعبیه‌شده،

توسط @gaborbernat https://github.com/gaborbernat. (#1883 https://github.com/pypa/virtualenv/issues/1883)

•
رفع مشکلی که در آن هنگام شکست در ایجاد تصویر بذرپاش‌های app-data، استثنا در سکوت نادیده گرفته می‌شد. جلوگیری از تداخل فرایندهای ایجاد دو محیط مجازی با یکدیگر با استفاده از قفل هنگام ایجاد تصاویر پایه. توسط @gaborbernat https://github.com/gaborbernat. (#1869 https://github.com/pypa/virtualenv/issues/1869)

•
اطمینان از اینکه بسته‌های بذرپاشی‌شده بیش از حد قدیمی نشوند:
  • افزودن پرچم خط فرمان برای شروع ارتقای wheelهای تعبیه‌شده تحت upgrade-embed-wheels <#upgrade-embed-wheels>
  • ارتقای دوره‌ای (هر ۱۴ روز یک‌بار) wheelهای تعبیه‌شده در فرایندی در پس‌زمینه، و استفاده از آن‌ها در صورتی که بیش از ۲۸ روز از انتشارشان گذشته باشد (از طریق no-periodic-update <#no-periodic-update> قابل غیرفعال‌سازی است)

جزئیات بیشتر در Wheel acquisition <#wheels> - توسط @gaborbernat https://github.com/gaborbernat. (#1821 https://github.com/pypa/virtualenv/issues/1821)

•
ارتقای محتوای wheelهای تعبیه‌شده:
  • ارائه بسته‌های wheel برای Python 3.9 و 3.10
  • ارتقای setuptools برای Python 3.5+ از 47.1.1 به 47.3.1

توسط @gaborbernat https://github.com/gaborbernat. (#1841 https://github.com/pypa/virtualenv/issues/1841)

•
نمایش نسخه‌های بسته‌های بذر (seed) نصب‌شده در خروجی نهایی خلاصه، به عنوان مثال:
created virtual environment CPython3.8.3.final.0-64 in 350ms
  creator CPython3Posix(dest=/x, clear=True, global=False)
  seeder FromAppData(download=False, pip=bundle, setuptools=bundle, wheel=bundle, via=copy, app_data_dir=/y/virtualenv)
    added seed packages: pip==20.1.1, setuptools==47.3.1, wheel==0.34.2

توسط @gaborbernat https://github.com/gaborbernat. (#1864 https://github.com/pypa/virtualenv/issues/1864)

•
رفع غلط املایی در setup.cfg - توسط @RowdyHowell https://github.com/RowdyHowell. (#1857 https://github.com/pypa/virtualenv/issues/1857)

•
تولید فایل ignore برای سامانه‌های کنترل نسخه جهت جلوگیری از ردیابی پیش‌فرض محیط‌های مجازی. در صورتی که کاربران همچنان مایل به ردیابی هستند باید این فایل‌ها را حذف کنند. در حال حاضر ما تنها از git پشتیبانی می‌کنیم - توسط @gaborbernat https://github.com/gaborbernat. (#1806 https://github.com/pypa/virtualenv/issues/1806)

•
وارد کردن (import) setuptools پیش از cli_run می‌توانست به دلیل وصله‌زدن distutils.dist.Distribution توسط setuptools باعث شکست استعلام اطلاعات python شود - توسط @gaborbernat https://github.com/gaborbernat. (#1771 https://github.com/pypa/virtualenv/issues/1771)

•
گسترش متغیرهای محیطی بررسی‌شده برای پیکربندی جهت بررسی نام‌های مستعار (مثلاً تنظیم هر یک از VIRTUALENV_COPIES یا VIRTUALENV_ALWAYS_COPY کارساز خواهد بود) - توسط @gaborbernat https://github.com/gaborbernat. (#1763 https://github.com/pypa/virtualenv/issues/1763)

•
اجازه دادن به فایل‌های wheel اولیه (seed wheel) در پوشه‌های extra-search-dir <#extra-search-dir> که فرادادهٔ Requires-Python برای آن‌ها مشخص نشده است؛ این فایل‌ها سازگار با تمام نسخه‌های python در نظر گرفته می‌شوند - توسط @gaborbernat https://github.com/gaborbernat. (#1757 https://github.com/pypa/virtualenv/issues/1757)

•
ارتقای setuptools تعبیه‌شده از 46.1.1 به 46.1.3 - توسط @gaborbernat https://github.com/gaborbernat. (#1752 https://github.com/pypa/virtualenv/issues/1752)

•
رفع شناسایی مفسر بر اساس نام از PATH در صورتی که با قالب spec مطابقت ندارد - توسط @gaborbernat https://github.com/gaborbernat. (#1746 https://github.com/pypa/virtualenv/issues/1746)

•
رفع شناسایی مفسرها از طریق مسیر نسبی - توسط @gaborbernat https://github.com/gaborbernat. (#1734 https://github.com/pypa/virtualenv/issues/1734)

•
بهبود پیام خطا هنگامی که پایتون میزبان پیش‌نیازهای لازم برای ایجاد محیط‌های مجازی را برآورده نمی‌کند (اکنون وقتی سازنده‌ای منطبق یافت نمی‌شود، اما سازندگانی وجود دارند که مفسر پایتون داده‌شده را توصیف می‌کنند، چاپ می‌شود که کدام فایل‌های میزبان ناسازگار/مفقود هستند و برای کدام سازندگان - همچنان عدم پشتیبانی از سازنده برای Jython چاپ می‌شود، اما در مورد CPython/PyPy دقیقاً مشخص می‌شود کدام فایل‌های میزبان مانع ایجاد محیط‌های مجازی هستند) - توسط @gaborbernat https://github.com/gaborbernat. (#1716 https://github.com/pypa/virtualenv/issues/1716)

•
بخش پشتیبانی <#compatibility-requirements> اکنون به صراحت مشخص می‌کند که از کدام نسخه‌های نصب‌شدهٔ Python پشتیبانی می‌شود - توسط @gaborbernat https://github.com/gaborbernat. (#1714 https://github.com/pypa/virtualenv/issues/1714)

•
غیرفعال‌سازی اصلاحیهٔ distutils برای python 3 تا زمانی که pypa/pip #7778 https://github.com/pypa/pip/issues/7778 برطرف و منتشر شود - توسط @gaborbernat https://github.com/gaborbernat. (#1669 https://github.com/pypa/virtualenv/issues/1669)

  • پوشهٔ داده‌های برنامه اکنون از طریق app-data <#app-data> قابل کنترل است،
  • گزینهٔ clear-app-data اکنون کل پوشهٔ داده‌های برنامه را پاک‌سازی می‌کند، نه فقط مسیر بذرپاش app-data،
  • بررسی اینکه آیا مسیر داده‌های برنامهٔ ارائه‌شده وجود ندارد یا فقط‌خواندنی است، و بازگشت خودکار به یک دایرکتوری موقت،
  • داده‌های برنامه در دایرکتوری موقت به طور خودکار در پایان اجرا پاک‌سازی می‌شوند،
  • مقدار symlink-app-data <#symlink-app-data> در زمانی که داده‌های برنامه موقت هستند، همیشه False است

توسط @gaborbernat https://github.com/gaborbernat. (#1640 https://github.com/pypa/virtualenv/issues/1640)

•
هنگام ساخت نام مستعار برای مفسرها، از پیوندهای نمادین نسبی استفاده شود - توسط @asottile https://github.com/asottile. (#1596 https://github.com/pypa/virtualenv/issues/1596)

•
مستندسازی یک API برنامه‌نویسی به صورت from virtualenv import cli_run ذیل Python <#programmatic-api> - توسط @gaborbernat https://github.com/gaborbernat. (#1585 https://github.com/pypa/virtualenv/issues/1585)

  • پشتیبانی از نام‌های مسیر طولانی برای نقطه‌های ورود کنسولی محیط مجازیِ تولیدشده (مانند pip) هنگام استفاده از app-data seeder <#seeder> - توسط @gaborbernat https://github.com/gaborbernat. (#997 https://github.com/pypa/virtualenv/issues/997)
  • بهبود سازوکار شناسایی python:
  • در صورت وجود فایل‌های اجرایی در PATH که پرس‌وجوی آن‌ها ناموفق است (مثلاً به دلیل عدم دسترسی اجرا به آن)، عملیات با شکست مواجه نشود،
  • علاوه بر پوشه پیشوند، پوشه باینری وابسته به سکو درون آن نیز بررسی شود،

توسط @gaborbernat https://github.com/gaborbernat. (#1545 https://github.com/pypa/virtualenv/issues/1545)

  • هنگام رونوشت‌برداری (چه فایل‌ها یا درخت‌ها)، بیت‌های مجوز، زمان آخرین دسترسی، زمان آخرین تغییر و پرچم‌ها کپی نشوند؛ چرا که ممکن است دسترسی به این موارد ممنوع باشد (مثلاً در مورد Framework Python در macOs) و برای استفاده کاربر از محیط مجازی نیازی به آن‌ها نیست - توسط @gaborbernat https://github.com/gaborbernat. (#1561 https://github.com/pypa/virtualenv/issues/1561)
  • هنگام شناسایی فایل‌های اجرایی python، مفسرهایی که قابل پرس‌وجو نیستند اکنون به‌جای warning با سطح info نمایش داده می‌شوند؛ بنابراین دیگر به‌طور پیش‌فرض نشان داده نمی‌شوند (این‌ها ممکن است صرفاً فایل‌های اجرایی باشند که به آن‌ها دسترسی نداریم یا خراب هستند؛ اگر Python هدف مورد نظر ما نیست هشدار داده نشود) - توسط @gaborbernat https://github.com/gaborbernat. (#1574 https://github.com/pypa/virtualenv/issues/1574)
  • بخش app-data seeder <#seeder> دیگر بسته‌ها را در UNIX پیوند نمادین (symlink) و در Windows کپی نمی‌کند. در عوض به‌طور پیش‌فرض همیشه کپی می‌کند، اما اکنون دارای پرچم symlink-app-data <#symlink-app-data> است که به کاربران اجازه می‌دهد این روش کم‌تر پایدار اما سریع‌تر را درخواست کنند - توسط @gaborbernat https://github.com/gaborbernat. (#1575 https://github.com/pypa/virtualenv/issues/1575)

•
ارتقای setuptools تعبیه‌شده به 45.2.0 از 45.1.0 برای Python 3.4+ - توسط @gaborbernat https://github.com/gaborbernat. (#1554 https://github.com/pypa/virtualenv/issues/1554)

  • محیط‌های مجازی ساخته‌شده از طریق مسیر نسبی در Windows، فایل‌های اجرایی کنسول نادرست ایجاد می‌کردند - توسط @gaborbernat https://github.com/gaborbernat. (#1552 https://github.com/pypa/virtualenv/issues/1552)
  • به نظر می‌رسد گاهی venvهای ایجادشده فایل اجرایی پایه خود را روی خودشان تنظیم می‌کردند؛ این موارد بدون راستی‌آزمایی پذیرفته می‌شدند، بنابراین محیط‌های مجازی را به عنوان پایتون سیستم در نظر می‌گرفت که باعث بروز مشکلاتی می‌شد - توسط @gaborbernat https://github.com/gaborbernat. (#1553 https://github.com/pypa/virtualenv/issues/1553)

•
رفع غلط‌های املایی، کلمات تکراری و فاصله‌گذاری ناهماهنگ سرعنوان‌ها. بازنویسی بخش‌هایی از مستندات توسعه و مستندات CLI. بسط دادن اختصاراتی مانند env var و config به شکل کامل آن‌ها. استفاده از توضیحات مستندات مربوطه برای پروژه‌های فهرست‌شده در related links - توسط @pradyunsg https://github.com/pradyunsg. (#1540 https://github.com/pypa/virtualenv/issues/1540)

•
بهبود سازوکار شناسایی فایل اجرایی پایه:
  • چاپ دلیل رد کردن برخی گزینه‌ها در سطح اشکال‌زدایی (debug)،
  • هنگامی که هیچ گزینه‌ای تطابق دقیق ندارد، به جای شکست قطعی، استفاده از نزدیک‌ترین تطابق با اولویت ویژگی‌های: پیاده‌سازی پایتون، نسخه اصلی (major)، نسخه فرعی (minor)، معماری، نسخه وصله (patch)، سطح انتشار و شماره سریال (این برای تسهیل کارکرد در زمانی است که ارتقای سیستم‌عامل، پایتون سیستم را با نسخه‌ای جدیدتر از آنچه پایتون میزبان virtualenv با آن ساخته شده جایگزین یا ارتقا می‌دهد)،
  • حل همیشگی اطلاعات system_executable در حین فرایند شناسایی مفسر، به طوری که محیط شناسایی‌شده به جای venv/virtualenv، مفسر سیستم باشد (این کار پیش‌تر به صورت تنبلانه در اولین دسترسی انجام می‌شد و باعث می‌شد گزارش شود که محیط مجازی ایجادشده از نوع نسخه پایتون میزبان virtualenv است، نه نسخه پایتون سیستم - این دو می‌توانند در صورتی که سیستم‌عامل پایتون سیستم را ارتقا داده باشد و میزبان virtualenv از طریق رونوشت ایجاد شده باشد، متفاوت باشند)،

توسط @gaborbernat https://github.com/gaborbernat. (#1515 https://github.com/pypa/virtualenv/issues/1515)

  • دیگر اطلاعات مفسرهای پذیرفته‌شده نمایش داده نمی‌شود (زیرا آخرین مورد پیشنهادشده همواره همان مورد پذیرفته‌شده است)،
  • عدم نمایش صفت str_spec برای PythonSpec زیرا می‌توان آن‌ها را از سایر صفت‌ها استنباط کرد،
  • برای بذرپاش (seeder) app-data نوع قفل نشان داده نمی‌شود، فقط مسیر دایرکتوری داده‌های برنامه نمایش داده می‌شود،

توسط @gaborbernat https://github.com/gaborbernat. (#1510 https://github.com/pypa/virtualenv/issues/1510)

  • نخستین انتشار عمومی از نسخهٔ بازنویسی‌شده؛ همه‌چیز کاملاً جدید بوده و به‌تازگی اضافه شده است.
  • مقدار پیش‌فرض --download برابر با False است
  • دیگر ماژول توکار site با نسخهٔ سفارشی تعبیه‌شده در خودِ کدِ virtualenv https://github.com/pypa/virtualenv/blob/legacy/virtualenv_embedded/site.py جایگزین نمی‌شود. تنها برای رفع اشکالات در Python 2 از یک ماژول رابط (shim) ساده استفاده شده است.

هشدار:

بستهٔ virtualenv کنونی دومین تکرار از پیاده‌سازی است. از نسخهٔ 0.8 تا 16.7.9 تکرار نخست شماره‌گذاری شده بود. نسخهٔ 20.0.0b1 یک بازنویسی کامل از این بسته است و از همین رو تاریخچهٔ این انتشار از آنجا آغاز می‌شود. گزارش تغییرات قدیمی همچنان در مستندات شاخهٔ قدیمی (legacy) https://virtualenv.pypa.io/en/legacy/changes.html در دسترس است.

نام نویسنده تعیین نشده است

2007-2026, PyPA, PyPA

September 1, 2026 21.7