pip, virtual environment আর pyproject — প্রতিটি প্রজেক্টের নিজের তাক

১ · আপনার প্রজেক্ট অন্যের কোডের ওপর দাঁড়িয়ে

নাদিয়া দুটি প্রজেক্ট নিয়ে কাজ করেন। একটি তাঁর বিশ্ববিদ্যালয়ের দলগত প্রজেক্ট — লাইব্রেরির বই ধার দেওয়ার একটি ওয়েবসাইট, দুই বছর আগে Django 4.2 দিয়ে বানানো। অন্যটি নতুন একটি ফ্রিল্যান্সিং কাজ — একটি দোকানের অর্ডার নেওয়ার সাইট, ক্লায়েন্ট চেয়েছেন Django 5.2. নাদিয়া নতুন কাজের জন্য Django আপডেট করলেন। পরদিন পুরোনো প্রজেক্ট চালাতেই লাল লেখা:

ImportError: cannot import name 'utc' from 'django.utils.timezone'

নাদিয়া পুরোনো প্রজেক্টের একটি লাইনও বদলাননি। তবু সেটি ভেঙে গেল। কারণ তাঁর কম্পিউটারে Django একটিই, আর দুটি প্রজেক্ট সেই একই Django ভাগ করছিল। Django 5.0-এ পুরোনো timezone.utc নামটি সরিয়ে দেওয়া হয়েছে — নতুন version-এর জন্য ঠিক, পুরোনো কোডের জন্য বিপদ।

এই পর্বের মূল সমস্যা এটিই। আজকের প্রায় কোনো Python প্রজেক্ট শুধু নিজের কোডে চলে না। ওয়েবসাইটে Django বা FastAPI, ডেটায় pandas, ইন্টারনেট থেকে ডেটা আনতে requests — এগুলো অন্য মানুষের লেখা package. আপনার প্রজেক্ট যেসব বাইরের package ছাড়া চলে না, সেগুলোই তার dependency. আর প্রতিটি dependency-র নির্দিষ্ট একটি version আপনার কোডের সাথে মেলে।

Package, distribution, wheel, sdist — কয়েকটি শব্দ পরিষ্কার করি

পর্ব ২২-এ দেখেছেন, module হলো একটি .py ফাইল, আর import করা যায় এমন package হলো module-এর একটি ফোল্ডার। কিন্তু PyPI-তে যা আপলোড হয় আর pip যা ইনস্টল করে, তার আসল নাম distribution — নাম আর version-সহ একটি বান্ডিল, যার ভেতরে এক বা একাধিক import-যোগ্য package থাকে। দৈনন্দিন কথায় দুটিকেই “package” বলা হয়, আর তাতে সমস্যা নেই। শুধু জেনে রাখুন, দুটির নাম সবসময় এক নয়: pip install beautifulsoup4 করে কোডে লেখেন import bs4, আর pip install pillow করে লেখেন import PIL.

একটি distribution দুই রূপে আসতে পারে:

wheel-এর নামের শেষ তিনটি অংশ পড়তে শিখুন। py3-none-any মানে “যেকোনো Python 3, কোনো C-অংশ নেই, যেকোনো OS” — বিশুদ্ধ Python package. আর NumPy-র মতো package-এর নামে থাকে cp313-cp313-win_amd64 — অর্থাৎ CPython 3.13, 64-বিট Windows-এর জন্য compile করা C extension. এজন্যই একদম নতুন Python version বেরোলে প্রথম কয়েক সপ্তাহ কিছু package ইনস্টল হতে চায় না — তাদের wheel তখনও তৈরি হয়নি।

২ · Virtual environment — প্রতিটি প্রজেক্টের নিজের তাক

নাদিয়ার সমস্যার সমাধান হলো প্রতিটি প্রজেক্টের ফোল্ডারে একটি করে virtual environment. এটি আসলে একটি সাধারণ ফোল্ডার (প্রথা অনুযায়ী নাম .venv), যার ভেতরে থাকে আসল Python-এর দিকে নির্দেশ করা একটি ছোট python, আর package রাখার নিজস্ব একটি site-packages ফোল্ডার। এই ফোল্ডারে যা ইনস্টল হয়, তা অন্য কোনো প্রজেক্ট দেখতে পায় না।

নিচের ডায়াগ্রামে দেখুন, একই কম্পিউটারে একই package-এর দুটি version কীভাবে শান্তিতে পাশাপাশি থাকে:

Python314/Lib/site-packages/
├── django/            (4.2)   ← library-project এর জন্য
└── requests/
library-project আর shop-project দুটিই এখান থেকে নেয়

$ pip install --upgrade django
Successfully installed django-5.2.x
$ cd library-project && python manage.py runserver
ImportError: cannot import name 'utc' from 'django.utils.timezone'

library-project/
├── manage.py
└── .venv/     ← নিজের python + নিজের site-packages
shop-project/
├── manage.py
└── .venv/

library-project/.venv/.../site-packages/django  (4.2.x)
shop-project/.venv/.../site-packages/django     (5.2.x)

(library-project) $ python -m django --version
4.2.x
(shop-project) $ python -m django --version
5.2.x

তৈরি ও চালু করা — আপনার যন্ত্র অনুযায়ী

প্রজেক্টের ফোল্ডারে terminal খুলে (VS Code-এ Ctrl+`) প্রথমে venv তৈরি করুন। -m venv মানে “এই Python-এর সাথে আসা venv module চালাও”, আর শেষের .venv হলো যে ফোল্ডার তৈরি হবে। যে Python দিয়ে venv বানাবেন, venv সেই version-এরই হবে।

py -m venv .venv              # অথবা: python -m venv .venv
.venv\Scripts\Activate.ps1    # চালু করা
deactivate                    # বন্ধ করা

.venv\Scripts\Activate.ps1 cannot be loaded because running scripts is disabled on this system.

Set-ExecutionPolicy -Scope CurrentUser RemoteSigned

py -m venv .venv
.venv\Scripts\activate.bat
deactivate

python3 -m venv .venv
source .venv/bin/activate
deactivate

চালু হলে প্রম্পটের শুরুতে বন্ধনীতে venv-এর নাম আসে — যেমন (.venv) PS C:\shop-project>. এটিই সবচেয়ে সহজ চিহ্ন যে আপনি তাকের ভেতরে আছেন। Windows আর Mac/Linux-এ ভেতরের গঠন সামান্য আলাদা:

৩ · Activate আসলে কী করে — PATH-এর খেলা

“Activate” শব্দটি শুনে মনে হয় ভেতরে বড় কোনো জাদু ঘটছে। আসলে ঘটে খুব ছোট একটি কাজ। পর্ব ০৩-এ দেখেছেন, terminal-এ python লিখলে shell PATH নামের ফোল্ডার-তালিকা ধরে ক্রমানুসারে খোঁজে, আর প্রথম মিলেই থামে। Activation শুধু এই তালিকার একেবারে শুরুতে venv-এর bin (Windows-এ Scripts) ফোল্ডারটি বসিয়ে দেয়। ফলে python আর pip লিখলে সবার আগে venv-এর ভেতরেরগুলো পাওয়া যায়। ধাপে ধাপে দেখুন (উদাহরণটি Linux-এর, Windows-এও হুবহু একই ঘটনা):

1$ which python32$ source .venv/bin/activate3(.venv) $ which python4(.venv) $ python -m pip install rich5(.venv) $ deactivate

এর একটি দারুণ ফল আছে: activate না করেও venv ব্যবহার করা যায়। সরাসরি .venv/bin/python app.py (Windows-এ .venv\Scripts\python.exe app.py) চালালে সেই python নিজেই জানে সে কোন venv-এর। সার্ভারে, cron-এ বা অটোমেশন স্ক্রিপ্টে সাধারণত এভাবেই চালানো হয় — সেখানে কেউ activate করে না।

আমি কি venv-এর ভেতরে? — কোড দিয়ে যাচাই

প্রম্পট দেখে বোঝা যায়, কিন্তু প্রোগ্রামের ভেতর থেকেও প্রশ্নটির উত্তর পাওয়া যায়। Python-এর দুটি মান আছে: sys.prefix (এখন যে পরিবেশ চলছে তার মূল ফোল্ডার) আর sys.base_prefix (আসল Python যেখানে ইনস্টল করা)। venv-এর ভেতরে দুটি আলাদা হয়ে যায়। চালিয়ে দেখুন:

import sys
import sysconfig
from pathlib import Path

# venv-এর ভেতরে থাকলে sys.prefix বদলে যায়, base_prefix থাকে আসল Python-এ
in_venv = sys.prefix != sys.base_prefix
print("venv-এর ভেতরে?", in_venv)

# pip যে ফোল্ডারে package বসায়, তার নাম
site_dir = Path(sysconfig.get_paths()["purelib"])
print("package-এর ফোল্ডার:", site_dir.name)
print("এই ফোল্ডার import-এর খোঁজার তালিকায়?", str(site_dir) in sys.path)
print("সব Python-এ venv module আছে?", "venv" in sys.stdlib_module_names)

VS Code আর git — দুটি জরুরি অভ্যাস

• VS Code-কে venv দেখিয়ে দিন। প্রজেক্ট-ফোল্ডারে .venv থাকলে VS Code সাধারণত নিজেই সেটি চিনে প্রস্তাব দেয়। না দিলে Ctrl+Shift+P → “Python: Select Interpreter” → .venv-এর python বাছুন। নিচের status bar-এ ('.venv') দেখলে নিশ্চিত। তারপর নতুন terminal খুললে VS Code নিজেই activate করে দেয়। “Python: Create Environment” কমান্ড দিয়ে VS Code থেকেই venv বানানো যায়।
• .venv কখনো git-এ নয়। এর ভেতরে শত শত মেগাবাইট ফাইল, আর সেগুলো আপনার OS ও আপনার ফোল্ডার-পথের সাথে বাঁধা — অন্য কারও কম্পিউটারে চলবেই না। .gitignore ফাইলে .venv/ লিখে দিন। Python 3.13 থেকে python -m venv নিজেই venv-এর ভেতরে একটি .gitignore রেখে দেয়, তবু প্রজেক্টের নিজের .gitignore-এ লাইনটি রাখা ভালো অভ্যাস। git-এ যাবে শুধু package-এর তালিকা — পরের অংশগুলোতে সেটিই দেখব।

# .gitignore — Python প্রজেক্টের ন্যূনতম
.venv/
__pycache__/
*.pyc
.env          # পাসওয়ার্ড, API key — কখনো git-এ নয়

৪ · pip — PyPI থেকে আপনার তাকে

venv চালু করার পর এবার package আনার পালা। pip-এর পাঁচটি কমান্ড দিয়েই দৈনন্দিন প্রায় সব কাজ চলে:

python -m pip install requests        # ইনস্টল (সাথে তার dependency-ও)
python -m pip install --upgrade requests   # নতুন version-এ আপগ্রেড
python -m pip uninstall requests      # সরানো (তার dependency থেকে যায়)
python -m pip list                    # এই পরিবেশে কী কী আছে
python -m pip show requests           # একটি package-এর বিস্তারিত
python -m pip freeze                  # সব package, হুবহু version-সহ

প্রতিটি কমান্ডের শুরুতে python -m pip কেন, শুধু pip কেন নয় — পর্ব ০৩-এ এর কারণ দেখেছেন: -m pip মানে “এই python-এর pip চালাও”, তাই package ঠিক সেই Python-এ যায়, যেটি দিয়ে কোড চলবে। venv চালু থাকলে pip আর python -m pip একই জিনিস, তবু অভ্যাসটি রাখলে কখনো ভুল Python-এ ইনস্টল হবে না। Windows-এ venv-এর বাইরে py -m pip.

pip show-এর ফল পড়তে শিখুন — সমস্যা খোঁজার সময় খুব কাজে লাগে:

(.venv) $ python -m pip show requests
Name: requests
Version: 2.32.3
Summary: Python HTTP for Humans.
Location: /home/rafi/shop/.venv/lib/python3.14/site-packages
Requires: certifi, charset-normalizer, idna, urllib3
Required-by:

Location বলে package কোন তাকে আছে — venv-এর ভেতরে, নাকি ভুল করে সিস্টেমে। Requires হলো এর নিজের dependency, আর Required-by বলে আপনার আর কোন package এর ওপর নির্ভর করে — সরানোর আগে এটি দেখে নিন। এবার দেখা যাক pip install requests লিখে Enter চাপলে ভেতরে কী কী ঘটে:

(.venv) $ python -m pip install requests
python = .venv/bin/python → pip = এই venv-এর pip

requests-2.32.3.tar.gz                (sdist)
requests-2.32.3-py3-none-any.whl      (wheel)
requests-2.32.2.tar.gz
… পুরোনো version-গুলো …

Requires-Python: >=3.8
Requires-Dist: charset_normalizer<4,>=2
Requires-Dist: idna<4,>=2.5
Requires-Dist: urllib3<3,>=1.21.1
Requires-Dist: certifi>=2017.4.17

Collecting requests
  Downloading requests-2.32.3-py3-none-any.whl
Collecting charset-normalizer<4,>=2 (from requests)
Collecting idna<4,>=2.5 (from requests)
Collecting urllib3<3,>=1.21.1 (from requests)
Collecting certifi>=2017.4.17 (from requests)

requests/                  ← import requests এটাই পায়
requests-2.32.3.dist-info/ ← নাম, version, ফাইলের তালিকা
urllib3/  idna/  certifi/  charset_normalizer/
Successfully installed certifi-… charset-normalizer-… idna-… requests-2.32.3 urllib3-…

দুটি জিনিস লক্ষ করুন। এক: আপনি একটি package চেয়েছেন, এসেছে পাঁচটি। বড় প্রজেক্টে সরাসরি dependency দশটি হলে transitive মিলিয়ে একশোও হতে পারে। দুই: pip uninstall requests শুধু requests সরায়, তার আনা চারটি থেকে যায় — pip জানে না সেগুলো আর কেউ ব্যবহার করে কি না। পরিষ্কার করতে চাইলে সবচেয়ে সহজ পথ: venv মুছে নতুন করে বানানো।

৫ · Version-এর ভাষা আর requirements.txt

“requests লাগবে” বলা যথেষ্ট নয় — কোন requests? নাদিয়ার গল্প মনে করুন: Django 4.2 আর 5.2 একই নামের দুটি ভিন্ন জিনিস। তাই dependency-র সাথে version-শর্ত লেখা হয়, যাকে বলে version specifier. নিয়মগুলো PEP 440-এ লেখা:

~= চিহ্নটির নাম “compatible release”, আর এটি বোঝার জন্য version নম্বরের প্রথা জানা দরকার। অনেক package semantic versioning-এর মতো চলে: MAJOR.MINOR.PATCH. পুরোনো কোড ভাঙে এমন বদলে MAJOR বাড়ে (4 → 5), নতুন সুবিধায় MINOR (4.1 → 4.2), শুধু বাগ ঠিকে PATCH (4.2.10 → 4.2.11). তবে এটি প্রতিশ্রুতি নয়, প্রথা — সব package কঠোরভাবে মানে না, Django-র নিজের নীতিও কিছুটা আলাদা। তাই শর্ত দিয়ে আশা করা যায়, নিশ্চিত হওয়া যায় না।

শর্তগুলো আসলে ছোট তুলনা মাত্র। নিচের কোডে সাধারণ string আর tuple দিয়ে ==, >= আর ~=-এর যুক্তি নিজে লিখে দেখা হয়েছে (আসল pip এর চেয়ে অনেক বেশি নিয়ম মানে — যেমন 2.0rc1-এর মতো version):

def ver(text):
    return tuple(int(part) for part in text.split("."))

def satisfies(installed, spec):
    for op in ("==", ">=", "~="):
        if op in spec:
            want = spec.partition(op)[2]
            break
    v, w = ver(installed), ver(want)
    if op == "==":
        return v == w
    if op == ">=":
        return v >= w
    # ~=4.2 মানে: অন্তত 4.2, কিন্তু শেষ অংশ ছাড়া বাকিটা মিলতে হবে (4.x)
    return v >= w and v[:len(w) - 1] == w[:-1]

checks = [("django~=4.2", "4.2.11"), ("django~=4.2", "5.0.3"),
          ("requests>=2.31", "2.32.3"), ("numpy==1.26.4", "2.1.0")]
for spec, installed in checks:
    result = "মেলে" if satisfies(installed, spec) else "মেলে না"
    print(f"{spec:<15} | ইনস্টল আছে {installed:<7} -> {result}")

requirements.txt — তাকের তালিকা

রাফি তাঁর দলের সঙ্গী তৃষাকে প্রজেক্টটি দিতে চান। .venv পাঠানো চলবে না (অংশ ২)। পাঠাতে হবে তাকের তালিকা, যাতে তৃষা নিজের কম্পিউটারে একই তাক সাজাতে পারেন। সবচেয়ে প্রচলিত তালিকার নাম requirements.txt — এক লাইনে একটি package. নামটি প্রথা, নিয়ম নয়, কিন্তু সবাই এটিই খোঁজে।

# রাফি: এখনকার venv-এর সব package, হুবহু version-সহ, ফাইলে
python -m pip freeze > requirements.txt

# তৃষা: git clone করার পর নিজের কম্পিউটারে
python -m venv .venv
.venv\Scripts\Activate.ps1          # Mac/Linux: source .venv/bin/activate
python -m pip install -r requirements.txt

pip freeze প্রতিটি ইনস্টল করা package name==version আকারে লেখে — transitive dependency-সহ। ফাইলটি দেখতে এমন:

certifi==2024.8.30
charset-normalizer==3.4.0
idna==3.10
requests==2.32.3
urllib3==2.2.3

এখানে একটি সূক্ষ্ম সমস্যা আছে। রাফি শুধু requests চেয়েছিলেন, কিন্তু তালিকায় পাঁচটি — কোনটি তাঁর সিদ্ধান্ত আর কোনটি শুধু সঙ্গে এসেছে, ফাইল দেখে বোঝা যায় না। বছরখানেক পরে requests বাদ দিলে বাকি চারটি অকারণে থেকে যাবে। তাই অভিজ্ঞরা প্রায়ই দুটি স্তর রাখেন: হাতে লেখা ছোট তালিকা (“আমি কী চাই” — যেমন requests>=2.31), আর সেখান থেকে টুল দিয়ে তৈরি সম্পূর্ণ, হুবহু তালিকা (“ঠিক কী ইনস্টল হবে”)। দ্বিতীয়টিই lock file-এর ধারণা — অংশ ৮-এ আসছে।

৬ · pyproject.toml — প্রজেক্টের পরিচয়পত্র

requirements.txt শুধু একটি package-তালিকা। কিন্তু প্রজেক্টের আরও পরিচয় আছে: তার নাম কী, version কত, কোন Python লাগে, terminal-এ কোন কমান্ড দিয়ে চালানো যায়, কোন টুলের কী সেটিং। এসব রাখার আধুনিক মানক জায়গা হলো pyproject.toml — প্রজেক্ট-ফোল্ডারের মূলে একটি ফাইল, যা TOML ভাষায় লেখা। পর্ব ২১-এর মাঝপথের প্রজেক্টের মতো একটি বাজার-হিসাবের CLI টুলের জন্য:

# pyproject.toml
[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"

[project]
name = "bazar-hisab"
version = "0.1.0"
description = "বাজারের খরচ হিসাব রাখার একটি CLI টুল"
requires-python = ">=3.10"
dependencies = [
    "rich~=13.7",
    "requests>=2.31",
]

[project.scripts]
bazar = "bazar_hisab.cli:main"

• [build-system] (PEP 518): এই প্রজেক্ট থেকে wheel বানাতে কোন টুল লাগবে। এই টুলকে বলে build backend — hatchling, setuptools, flit-core ইত্যাদি। pip নিজে build করে না; এই অংশ পড়ে backend-কে ডেকে আনে।
• [project] (PEP 621): নাম, version, বিবরণ, requires-python আর dependencies — সব টুলের বোঝার মতো মানক ঘর। পুরোনো দিনে এসব থাকত setup.py নামের একটি Python স্ক্রিপ্টে।
• requires-python: পুরোনো Python-এ কেউ ইনস্টল করতে চাইলে pip সঙ্গে সঙ্গে থামিয়ে দেবে — অদ্ভুত error-এর বদলে পরিষ্কার বার্তা।
• [project.scripts]: ইনস্টলের পর terminal-এ bazar লিখলেই bazar_hisab/cli.py-এর main() চলবে। pip venv-এর bin/Scripts-এ এই নামে ছোট একটি চালানোর ফাইল বানিয়ে দেয়।

খেয়াল করুন, এখানে dependency-গুলো তুলনামূলক ঢিলে শর্তে (~=, >=) লেখা। কারণ pyproject.toml বলে “এই প্রজেক্টের কী লাগে”, “ঠিক কোন version ইনস্টল হবে” নয়। হুবহু তালিকার কাজ lock file-এর।

নিজের প্রজেক্ট নিজেই ইনস্টল — editable mode আর src layout

বড় প্রজেক্টে প্রস্তাবিত সাজানো হলো src layout — import করা যায় এমন package-টি থাকে src/-এর ভেতরে:

bazar-hisab/
├── pyproject.toml
├── README.md
├── src/
│   └── bazar_hisab/
│       ├── __init__.py
│       └── cli.py
└── tests/
    └── test_cli.py

এভাবে রাখলে প্রজেক্টের মূল ফোল্ডার থেকে python চালালেও import bazar_hisab “ভুলবশত” কাজ করে না — package-টি সত্যিই ইনস্টল করা থাকতে হয়। শুনতে ঝামেলা মনে হলেও এটিই সুবিধা: আপনার কম্পিউটারে যা চলে, ইনস্টলের পর ব্যবহারকারীর কম্পিউটারেও তা-ই চলবে। কিন্তু প্রতিবার কোড বদলে আবার ইনস্টল? তার সমাধান editable install:

(.venv) $ python -m pip install -e .     # . মানে "এই ফোল্ডারের প্রজেক্ট"
(.venv) $ bazar --help                   # [project.scripts]-এর কমান্ড এখন চলে

-e (editable) দিলে pip site-packages-এ আপনার কোডের কপি বসায় না, বসায় আপনার src/ ফোল্ডারের দিকে একটি নির্দেশ। এখন cli.py-তে কিছু বদলালেই পরের বার চালানোয় সেটি দেখা যায়। সঙ্গে dependencies-এর তালিকাও ইনস্টল হয়ে যায়। তৃষা git clone করে শুধু venv বানিয়ে pip install -e . দিলেই পুরো প্রজেক্ট প্রস্তুত। পর্ব ৩৯-এ pytest দিয়ে টেস্ট লেখার সময় এই সাজানো খুব কাজে লাগবে।

৭ · আধুনিক টুল আর “externally-managed-environment”

venv আর pip Python-এর সাথেই আসে, আর সব জায়গায় চলে — এই পর্বের ভিত এ দুটিই। তবে বাস্তবে আরও কিছু টুল দেখবেন। কোনটি কেন আছে, জানা থাকলে বিভ্রান্তি কমে:

# একই কাজ uv দিয়ে — তুলনার জন্য
uv venv                    # .venv তৈরি
uv pip install requests    # pip-এর মতো ইনস্টল
uv add requests            # pyproject.toml-এ যোগ + uv.lock আপডেট
uv run python app.py       # ঠিক venv দিয়ে চালানো, activate ছাড়াই

কোনটি বাছবেন? শেখার সময় venv + pip — এগুলো সবখানে আছে, আর অন্য সব টুল এই ধারণার ওপরেই দাঁড়িয়ে। দল বা চাকরিতে গেলে সেখানে যা চলে, সেটি। আর ABCL TECH-এর AI-এর জন্য Python কোর্সের venv পর্বে conda আর uv-এর আরও ব্যবহারিক তুলনা আছে। টুল বদলায়, কিন্তু চারটি ধারণা একই থাকে: আলাদা পরিবেশ, version-শর্ত, তালিকা আর lock.

“externally-managed-environment” — OS যখন বলে “আমার Python-এ হাত দেবেন না”

নতুন Linux (যেমন Debian 12, Ubuntu 23.04 থেকে) বা Mac-এর Homebrew Python-এ venv ছাড়া pip install দিলে এমন বার্তা আসে:

error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
    python3-xyz, where xyz is the package you are trying to
    install. ... you may create a virtual environment ...

এটি ভুল নয়, ইচ্ছাকৃত সুরক্ষা — PEP 668. Linux-এর অনেক সিস্টেম-টুল Python-এ লেখা, আর সেগুলো OS-এর apt দিয়ে আনা নির্দিষ্ট version-এর package-এর ওপর নির্ভর করে। আপনি pip দিয়ে সেই একই তাকে কোনো package-এর ভিন্ন version বসালে OS-এর টুল ভাঙতে পারে। তাই OS তার Python-কে “externally managed” ঘোষণা করে, আর pip সেখানে লিখতে অস্বীকার করে। সমাধানের পথ:

• প্রজেক্টের জন্য: venv বানান — ঠিক এই পর্বে যা শিখলেন। বার্তাটি আসলে এটাই বলছে।
• Terminal-টুলের জন্য: pipx install ...
• OS-এর নিজের প্রয়োজনে: sudo apt install python3-requests-এর মতো OS-এর package.
• যা করবেন না: sudo pip install বা --break-system-packages. দ্বিতীয়টির নামেই সতর্কবার্তা — “সিস্টেমের package ভাঙুক”। AI প্রায়ই এটি বলে দেয় (অংশ ৯)।

বাস্তব উদাহরণ: admin অধিকার ছাড়া ল্যাবের কম্পিউটার

রাকিব একটি প্রশিক্ষণ কেন্দ্রের শেয়ার করা কম্পিউটারে কাজ করেন, admin অধিকার নেই। pip install pandas দিতেই আসে Permission denied — কারণ সিস্টেমের Python-এর ফোল্ডারে লেখার অনুমতি তাঁর নেই। এখানে venv-ই সবচেয়ে পরিষ্কার সমাধান: venv তৈরি হয় রাকিবের নিজের ফোল্ডারে, যেখানে তাঁর লেখার অধিকার আছে, তাই কোনো admin অধিকার লাগে না, অন্য কারও কাজেও হাত পড়ে না। পুরোনো বিকল্প pip install --user package-কে ব্যবহারকারীর ব্যক্তিগত ফোল্ডারে বসায়, কিন্তু সেখানেও সব প্রজেক্ট এক তাক ভাগ করে, আর PEP 668-যুক্ত সিস্টেমে এটিও আটকানো। তাই প্রজেক্টের কাজে venv. দিনের শেষে প্রজেক্ট-ফোল্ডারসহ venv মুছে দিলে পরের জনের জন্য কম্পিউটার পরিষ্কার থাকে।

৮ · Dependency hell, lock file আর package-এর নিরাপত্তা

ধরুন আপনার প্রজেক্টে দুটি package: একটি চায় urllib3<2, অন্যটি চায় urllib3>=2. দুটির শর্ত একসাথে পূরণ করা অসম্ভব — একটি venv-এ একটি package-এর একটিই version থাকতে পারে। এমন জট আর তার পরের দিনভর “কোন version মেলে” খোঁজার নাম dependency hell. pip তখন সোজাসুজি বলে দেয়:

ERROR: Cannot install pkg-a and pkg-b because these package versions have conflicting dependencies.
ERROR: ResolutionImpossible

pip 20.3 (২০২০) থেকে নতুন resolver এমন জট ইনস্টলের আগেই ধরে। আগে pip প্রায়ই চুপচাপ একটি ভুল সেট ইনস্টল করে ফেলত, আর ভাঙন ধরা পড়ত পরে। সমাধানের সাধারণ পথ: কোনো একটি package-এর অন্য version খোঁজা (হয়তো নতুন version urllib3 2 সমর্থন করে), বা অপ্রয়োজনীয় package বাদ দেওয়া।

Lock file — “আমার কম্পিউটারে তো চলে” সমস্যার উত্তর

Lock file হলো resolve করার পরের সম্পূর্ণ ছবি: প্রতিটি package (transitive-সহ), তার হুবহু version, আর প্রায়ই ফাইলের hash. uv লেখে uv.lock, Poetry লেখে poetry.lock; pip-tools-এর pip-compile হাতে লেখা ছোট তালিকা থেকে hash-সহ requirements.txt বানায়। ২০২৫ সালে PEP 751 সব টুলের জন্য একটি সাধারণ lock-ফরম্যাট (pylock.toml) মেনে নিয়েছে, টুলগুলো ধীরে ধীরে তা সমর্থন করছে।

Package-এর নিরাপত্তা — PyPI-তে যে কেউ আপলোড করতে পারে

PyPI একটি খোলা ভাণ্ডার: অ্যাকাউন্ট খুলে যে কেউ package আপলোড করতে পারে, কেউ আগে থেকে কোড পরীক্ষা করে দেয় না। আর pip install অনেক সময় package-এর কোড আপনার কম্পিউটারে চালায়ও — বিশেষ করে sdist build করার সময়। তাই ভুল package ইনস্টল মানে অচেনা কারও কোড আপনার কম্পিউটারে, আপনার ফাইল আর পাসওয়ার্ডের কাছে চালানো। আপনি যে package-গুলোর ওপর দাঁড়িয়ে আছেন, সেখানে ক্ষতিকর কোড ঢুকিয়ে আক্রমণকে বলে supply-chain attack. সবচেয়ে সাধারণ ফাঁদগুলো:

• Typosquatting: জনপ্রিয় নামের কাছাকাছি বানানে ক্ষতিকর package — reqeusts, python3-dateutil (আসলটি python-dateutil), jeIlyfish (ছোট হাতের l-এর জায়গায় বড় হাতের I; আসলটি jellyfish). এক অক্ষরের টাইপ-ভুলেই ফাঁদে পা।
• Slopsquatting: AI কখনো কখনো আত্মবিশ্বাসের সাথে এমন package-নাম বলে, যা আসলে নেই। গবেষকেরা দেখিয়েছেন, এমন বানানো নাম বারবার একই রকম আসে — তাই আক্রমণকারী আগেই সেই নামে ক্ষতিকর package আপলোড করে রাখতে পারে।
• Dependency confusion: কোনো প্রতিষ্ঠানের ভেতরের package-এর নামেই পাবলিক PyPI-তে package রাখা, যাতে ইনস্টলার ভুলটি নামায়।

AI কোনো অচেনা package-এর নাম বললে কী যাচাই করবেন, ধাপে ধাপে দেখুন:

"বাংলা তারিখ রূপান্তরের জন্য এটি ইনস্টল করুন:
  pip install bangla-date-utils"
নামটি আপনি আগে কখনো শোনেননি

requests        ✓ আসল
reqeusts        ✗ e আর u-র জায়গা বদল
request         ✗ শেষের s নেই
beautifulsoup4  ✓ আসল   beautifulsoup ✗ পুরোনো/ভিন্ন

✗ পাতাই নেই        → AI নাম বানিয়েছে; ইনস্টল নয়
✗ গত সপ্তাহে তৈরি, একটিমাত্র version, বিবরণ ফাঁকা
✗ source repository-র লিংক নেই
✓ বহু বছরের ইতিহাস, পরিচিত repo, নিয়মিত release

(.venv) $ python -m pip install "requests==2.32.3"
(.venv) $ python -m pip freeze > requirements.txt

(.venv) $ python -m pip install pip-audit
(.venv) $ pip-audit
No known vulnerabilities found
ত্রুটি পেলে: package, version, ত্রুটির ID আর কোন version-এ ঠিক হয়েছে

৯ · AI-এর যুগে — AI-এর ইনস্টল-পরামর্শ যাচাই

“ModuleNotFoundError এলে কী করব?” — AI-কে জিজ্ঞেস করলে প্রায়ই সঙ্গে সঙ্গে একটি ইনস্টল-কমান্ড পাবেন। অনেক সময় সেটি ঠিকই থাকে। কিন্তু AI মডেল ইন্টারনেটের বহু বছরের লেখা থেকে শেখে, যার বড় অংশ venv আর PEP 668-এর আগের যুগের। আর package-এর নামের ক্ষেত্রে AI-এর ভুল শুধু বিরক্তিকর নয়, বিপজ্জনক। এই ভুলগুলো চিনে রাখুন:

AI-এর দেওয়া কোনো ইনস্টল-কমান্ড চালানোর আগে — চেকলিস্ট

• প্রম্পটে (.venv) দেখছি — অর্থাৎ সঠিক প্রজেক্টের venv চালু
• package-এর নাম pypi.org-এ খুঁজে পেয়েছি; বয়স, repo আর লেখক দেখে বিশ্বাসযোগ্য মনে হয়েছে
• নামের বানান অক্ষর ধরে মিলিয়েছি, import-নাম আর distribution-নাম গুলিয়ে ফেলিনি
• কমান্ডে sudo, --break-system-packages বা অচেনা কোনো --index-url নেই
• ইনস্টলের পর version pin করে requirements.txt বা pyproject.toml আপডেট করেছি, আর মাঝে মাঝে pip-audit চালাই