uv: quản lý môi trường Python nhanh hơn hẳn

Trả lời nhanh: uv là công cụ gộp mọi việc quản lý môi trường Python vào một chỗ: tạo môi trường ảo, cài gói, khóa phiên bản, và cài luôn bản Python nếu máy chưa có. Điểm gây chú ý nhất là tốc độ, thường nhanh hơn công cụ truyền thống hàng chục lần nhờ viết bằng ngôn ngữ biên dịch và có bộ nhớ đệm chung. Nó đọc được các file khai báo quen thuộc nên chuyển sang không phải viết lại gì, và bạn vẫn quay về công cụ cũ bất cứ lúc nào.

Ai làm Python đều quen cảnh ngồi chờ cài thư viện, nhất là những gói phải biên dịch. Trên máy chủ nhỏ, một lần cài đầy đủ có khi mất cả chục phút. uv rút phần lớn thời gian đó xuống còn vài giây, và đó là lý do nó lan nhanh dù còn mới.

Cài và các lệnh dùng hằng ngày

# Cai cong cucurl -LsSf https://astral.sh/uv/install.sh | sh # Tao moi truong ao va cai goiuv venvuv pip install -r requirements.txt # Chay lenh trong moi truong ma khong can kich hoatuv run python xu-ly.py # Cai luon ban Python neu may chua couv python install 3.13

Lệnh chạy trực tiếp là thứ tiện nhất trong nhóm: bạn không phải nhớ kích hoạt môi trường trước, nó tự dùng đúng môi trường của thư mục hiện tại. Trên máy chủ, điều này loại bỏ hẳn một nguồn lỗi kinh điển là chạy script bằng Python hệ thống thay vì Python của môi trường ảo.

Khả năng tự cài bản Python cũng đáng chú ý: bạn không cần thêm một công cụ riêng để quản lý phiên bản, và trên máy chủ mới thì đây là cách nhanh nhất để có đúng bản mà dự án cần.

Vì sao nhanh hơn nhiều

Ba lý do kỹ thuật, và chúng giải thích vì sao khác biệt lớn tới vậy:

• Viết bằng ngôn ngữ biên dịch nên phần giải quyết phụ thuộc chạy nhanh hơn hẳn so với công cụ viết bằng chính Python.
• Bộ nhớ đệm chung toàn máy. Một gói đã tải về thì các dự án khác dùng lại, không tải lại và không chép lại.
• Cài song song. Nhiều gói được tải và giải nén cùng lúc thay vì lần lượt.

Điểm thứ hai có tác dụng phụ rất đáng giá trên máy chủ nhỏ: nhiều dự án dùng chung gói thì tiết kiệm cả dung lượng ổ đĩa, không còn cảnh mỗi môi trường ảo chiếm vài trăm MB cho cùng bộ thư viện.

Với máy CI, khác biệt còn rõ hơn vì mỗi lượt build đều phải cài lại từ đầu. Giữ được bộ nhớ đệm giữa các lượt là một trong những lý do máy tự dựng nhanh hơn dịch vụ dùng chung, như đã nói ở bài runner tự host.

Khóa phiên bản cho máy chủ chạy đúng bộ

# Khai bao phu thuoc va sinh file khoauv add fastapi uvicornuv lock # Tren may chu: cai dung bo da khoauv sync --frozen

File khóa ghi lại chính xác từng gói và từng phiên bản, kể cả các phụ thuộc gián tiếp. Nhờ vậy máy chủ cài đúng bộ như máy bạn, thay vì nhận một bản mới hơn của thư viện phụ nào đó và hỏng theo cách khó hiểu.

Tham số đóng băng ở lệnh cuối quan trọng trên máy chủ: nó bảo công cụ không được tự cập nhật file khóa, chỉ cài đúng những gì đã ghi. Thiếu tham số này thì môi trường máy chủ có thể lệch khỏi thứ bạn đã kiểm thử.

Nguyên tắc này giống hệt cách quản lý bản Node trong bài node version manager: một nguồn sự thật duy nhất trong repo, và máy chủ đọc theo đó chứ không tự quyết.

Trên máy chủ và trong Docker

Với ảnh Docker, dùng công cụ này rút ngắn thời gian dựng ảnh đáng kể. Mẫu thường dùng:

FROM python:3.13-slimCOPY --from=ghcr.io/astral-sh/uv:latest /uv /bin/uv WORKDIR /appCOPY pyproject.toml uv.lock ./RUN uv sync --frozen --no-dev COPY . .CMD ["uv", "run", "python", "-m", "ung_dung"]

Thứ tự các dòng ở đây quan trọng: chép file khai báo trước rồi cài, sau đó mới chép mã nguồn. Nhờ vậy khi bạn chỉ sửa code mà không đổi thư viện, Docker dùng lại lớp đã cài và bỏ qua bước cài. Nguyên tắc phân lớp này nằm ở bài Docker Compose.

Trên máy chủ chạy dịch vụ thật, nhớ dùng đường dẫn tuyệt đối trong khai báo dịch vụ hệ thống, vì dịch vụ không chạy qua shell đăng nhập của bạn nên không thấy các biến môi trường mà công cụ thiết lập.

Khi nào vẫn nên dùng công cụ cũ

Nói cho công bằng, có vài chỗ chưa nên vội chuyển:

• Dự án phụ thuộc vào công cụ đóng gói đặc thù chưa được hỗ trợ đầy đủ.
• Môi trường khoa học dữ liệu phức tạp với nhiều gói nhị phân nặng, nơi hệ sinh thái quản lý gói riêng vẫn xử lý tốt hơn.
• Quy trình của công ty đã ổn định và không có ai rảnh để rà lại. Tốc độ hay nhưng chưa chắc đáng đánh đổi bằng một đợt di chuyển giữa mùa cao điểm.

Điểm an tâm: vì nó đọc các file khai báo tiêu chuẩn, bạn thử trên một dự án nhỏ trước và quay lại bất cứ lúc nào, không bị khóa vào đâu. Đó cũng là cách thử hợp lý nhất với mọi công cụ mới.

Khóa phiên bản để máy chủ chạy đúng bộ

# Tao file khoa phien ban, va DUA VAO KHO MA NGUONuv lock # Tren may chu: cai dung bo da khoa, khong tu giai lai phu thuocuv sync --frozen # Kiem bo dang caiuv pip list # Trong Dockerfile: chep file khoa truoc, cai, roi moi chep ma nguon# Cach nay tan dung duoc bo nho dem giua cac lan dung

Đây là điểm quan trọng nhất và cũng là lý do chính đáng nhất để đổi công cụ: có tệp khóa phiên bản đầy đủ nghĩa là máy chủ chạy đúng bộ thư viện bạn đã thử, không phải bộ mới nhất tại thời điểm triển khai. Rất nhiều sự cố kiểu chạy được hôm qua mà hôm nay hỏng đến từ chỗ này.

Vì sao nhanh hơn và điều đó đáng bao nhiêu

• Khác biệt rõ nhất ở khâu cài thư viện, nhất là khi cài lại từ đầu. Với quy trình tự động chạy nhiều lần mỗi ngày, thời gian cộng dồn đáng kể.
• Trên máy phát triển, khác biệt ít cảm nhận hơn vì bạn ít khi cài lại từ đầu.
• Đo trên chính dự án của bạn trước khi quyết định đổi: xóa thư mục môi trường ảo rồi tính giờ cài lại bằng cả hai công cụ.

Dự án đang chạy ổn thì đừng đụng nền móng

• Dự án đang chạy ổn định và không có vấn đề gì. Đổi công cụ quản lý phụ thuộc là việc chạm vào nền móng, đừng làm khi không cần.
• Có thư viện phụ thuộc vào cách cài đặc thù của công cụ cũ.
• Đội chưa ai dùng và dự án đang gấp.
• Cách chuyển ít rủi ro nhất: dùng công cụ mới trên một dự án mới trước, để quen, rồi mới tính tới các dự án đang chạy.