Trải nghiệm lần đầu viết thư viện Python từ ngôn ngữ biên dịch

2204

Tác giả: Nguyễn Hồng Quân

Có một người bạn mà mình từng ngồi nhiều cafe để bàn về những công nghệ mới để phục vụ cho dự án công ty. Một câu hỏi mà bạn hay đặt ra là dùng ngôn ngữ lập trình gì tiếp theo. Mình thì khá dày dạn về Python và đã từng xây dựng nền móng cho những dự án Python ở công ty bạn. Tuy nhiên, mình và bạn đều đồng ý là nên mở rộng phạm vi công nghệ để thích ứng với nhiều thể loại dự án khác nhau. Đi tham vấn nhiều nơi, được nghe khen ngợi về Go nên bạn rất muốn một lần được áp dụng Go trong cty của bạn. Còn mình thì, nếu đã chọn một ngôn ngữ biên dịch và phải bỏ thời gian cá nhân ra học thì mình thà chọn Rust hơn. Tất nhiên, ý thức được độ khó của Rust nên mình chả bao giờ muốn đem Rust vào công ty của bạn cả.

Trong khi lý do thường được nêu ra để chọn Go là cú pháp đơn giản, ít keyword, dễ học, thì với mình, độ khó của Rust là thứ đáng để đầu tư. Thà chịu khó ban đầu nhưng gặt hái kết quả tốt về sau.

Ngoài ra, điều khiến mình ưu ái Rust hơn Go là ở chỗ Rust không có garbage collector, không có runtime riêng, nên có thể dùng Rust để viết thư viện tầng dưới, phục vụ cho Python và các ngôn ngữ khác được, chưa kể, việc được thiết kế tốt và không có bộ runtime khiến Rust là ngôn ngữ duy nhất (ngoài C) khiến tác giả của Linux muốn thấy nó được ứng dụng vào nhân Linux. Lý do viết thư viện đã được mình hiện thực hóa, bằng một sản phẩm cá nhân là Defity, thư viện dành cho Python và dùng để nhận dạng loại file.

Defity

Hoàn cảnh ra đời

Câu chuyện ra đời của Defity cũng hơi lòng vòng. Mình chủ yếu làm việc bên backend nên hay đảm nhận việc thiết kế, viết API server cho các ứng dụng khác gọi vào, trong đó có chức năng upload. Và để thống nhất với các phần khác của API, mình cho dữ liệu upload ở dạng JSON luôn (trong ứng dụng HTTP thông thường thì việc upload dùng content type multipart), trong đó nội dung nhị phân của file sẽ được chuyển mã base64 để thành dạng text, đưa vào JSON.

Trong quá trình viết API thì mình phải test từng bước từng bước để xem phần mình vừa làm đã chạy đúng ý chưa. Quá trình test API này, thông thường người khác sẽ dùng công cụ như Postman, nhưng mình là dân Linux, làm việc nhiều trên Terminal nên mình ưa các công cụ dòng lệnh hơn.

Mình thường kết hợp jo và HTTPie để tạo request, gọi API HTTP trên Terminal, ví dụ:

$ jo -d. file.name=image.png file.content=%image.png | http example-api.vn/ekyc/

Chỉ thị % của jo là để yêu cầu jo đọc nội dung file và chuyển hóa thành base64. Lệnh jo phía trên sẽ tạo ra nội dung JSON dạng như:

{
  "file": {
    "name": "image.png",
    "content": "iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAAAAAA6fptVAAABI2..."
  }
}

Bên lề một xíu, API phía trên là mình viết cho một dự án nội bộ về eKYC, để đọc dữ liệu từ ảnh chụp CMND/CCCD, và nhận diện khuôn mặt, và phần server API mình dựa trên FastAPI (nhưng mình không làm lớp OCR, AI vì lớp đó đang dùng dịch vụ bên khác cung cấp).

Sau đó mình tham gia một dự án khác, cũng cần cung cấp chức năng upload qua API. Dự án này thì backend dựa trên Django và Django Rest Framework. Bên Django thì thư viện phong phú nên trước khi xắn tay vào làm thì mình thường kiểm tra coi đã có thư viện cho chức năng mình định làm chưa. Và thật thú vị là có luôn, đó là drf_base64. Tuy nhiên, khác với cách làm của mình trong dự án eKYC bên trên thì drf_base64 quy ước dữ liệu upload ở dạng Data URL, ví dụ data:image/gif;base64,R0lGODlhEAAQAMQAAORHHOVS... tức là ngoài chuỗi base64 còn phải kèm thêm thông tin “MIME type” của file ban đầu.

Để test API kiểu này thì mình cần công cụ dòng lệnh để sinh ra chuỗi Data URL như trên. Tìm các phần mềm có sẵn thì chỉ thấy datauri-cli, một phần mềm viết bằng NodeJS. Mình khá ngại các phần mềm viết bằng NodeJS vì nó hay tạo thư mục node_modules chiếm nhiều dung lượng đĩa, nên quyết định tự viết phần mềm mới. Nếu viết bằng Python, mình chỉ cần chục phút là xong, không kể thời gian viết tài liệu, unittest, sắp xếp chỉn chu để phát hành thành một dự án nguồn mở. Tuy nhiên, mình thấy đây là cơ hội để tranh thủ rèn luyện Rust nên quyết định viết bằng Rust. Thế là phần mềm Duri ra đời.

Có Duri thì kết hợp với jo và HTTPie như sau:

$ jo -d. file.name=image.png file.content=$(duri image.png) | http example-api.vn/ekyc/

Trong lúc viết Duri thì mình cần một thư viện Rust để nhận biết loại file và trả về tên MIME type, ví dụ image/png, image/jpeg, và mình tìm được tree_magic_mini. Thư viện dành cho mục đích này mình biết cũng nhiều, nhưng hầu hết là dựa trên libmagic. Bên phía server mình cũng cần thư viện loại này để kiểm tra file do người dùng upload lên, và từ chối nếu file không phù hợp. Ví dụ như ứng dụng eKYC bên trên, mình cần ảnh chụp CMND dưới dạng file hình ảnh hay PDF nhưng nếu người dùng upload file *.docx, *.exe lên thì phải từ chối và báo lỗi. Khi đọc mô tả của tree_magic_mini thì mình khá ấn tượng, và mình nghĩ đến việc ứng dụng nó bên phía server luôn. Để đưa được nó vào backend thì cần tạo thư viện Python phủ trên nó, và đây chính là cơ hội để mình tập viết một thư viện Python bằng ngôn ngữ Rust! Thành quả của lần mạnh dạn chơi lớn này là tạo ra Defity.

Để tạo ra lớp binding từ Rust sang Python thì mình dùng PyO3. Ở đây có sự chơi chữ. Tên “Rust” ban đầu là được lấy theo một loại nấm nhưng cộng đồng lại thích diễn giải nó theo nghĩa “rỉ sét”. Tương tự bên Python, tên nó được lấy theo một chương trình hài kịch, nhưng cộng đồng lại thích hiểu theo nghĩa là “trăn”. “Rỉ sét” nói theo khoa học là hiện tượng “oxy hóa”, nên PyO3 được đặt tên bắt chước công thức hóa học của một ô-xít.

Khi viết thư viện Python từ một ngôn ngữ biên dịch (C/C++, Rust) thì có 2 hướng làm:

  • Liên kết với mã nguồn C của trình thông dịch CPython (Python.h), gọi các hàm được định nghĩa trong đây, theo một quy ước để trình thông dịch nhận diện mình là một module.
  • Không liên kết với mã nguồn của CPython. Thay vào đó, cứ biên dịch ra file thư viện liên kết động (*.so, *.dll), theo giao diện nhị phân quy ước bởi ngôn ngữ C, rồi bên phía Python dùng ctypes để truy cập vào các hàm, kiểu dữ liệu C trong file này.

Khi dùng PyO3 là ta đang di theo hướng thứ nhất. Mặc dù code ta viết là Rust nhưng bên dưới, PyO3 sẽ phụ trách việc liên kết với mã nguồn C của CPython. Nhờ những tính năng hiện đại của Rust (ví dụ phần macro mạnh mẽ) nên khi viết thư viện Python bằng Rust, ta có code ngắn hơn nhiều so với khi viết bằng C/C++.

Cấu trúc

Mã nguồn của Defity gồm hai phần:

1. Phần viết bằng Rust trong file src/lib.rs.

Đây là phần nhận dữ liệu từ Python, gọi với các hàm trong tree_magic_mini, và chuyển đổi đầu ra sao cho hợp với Python. Phần này cũng phụ trách tạo ra các hàm có tên và tham số sao cho đúng phong cách của Python. Ví dụ, tree_magic_mini đặt tên hàm from_u8 nghe rất tối nghĩa nếu dùng từ phía Python, vì trong Python không có kiểu dữ liệu nào tên là u8. Tại đây mình đặt ra hàm from_bytes để đúng với cách gọi của Python. Ngoài ra, tree_magic_mini còn có một hàm khác tên là from_filepath. Cách đặt tên này cho thấy nó chỉ nhận dữ liệu đầu vào là một đường dẫn file. Điều này thì không thỏa mãn ý đồ thiết kế của mình, nếu dùng bên phía Python. Bên phía Python mình muốn thiết kế hàm để nhận vào không chỉ đường dẫn file mà còn nhận vào một file object, như khi dùng với with open(), vì vậy mình đặt tên là from_file cho nó tổng quát hơn. Phần này cũng phụ trách tạo ra các thông báo lỗi theo đúng phong cách của Python. Ví dụ hàm from_filepath của tree_magic_mini có signature như sau:

pub fn from_filepath(filepath: &Path) -> Option<&'static str>

Có nghĩa là trả về None nếu file không tìm thấy hoặc file không thể mở. Như thế khá mơ hồ. Mình muốn nó bắn ra lỗi chi tiết hơn, ví dụ đối với Python, nếu không tìm thấy file thì quăng ra exception FileNotFoundError, nếu không có quyền mở file thì quăng ra exception PermissionError.

Ở đây, nhờ việc implement các trường hợp lỗi, mình hiểu rõ hơn về cách hoạt động của toán tử ?, trait From để chuyển đổi kiểu Error này sang Error khác một cách tự động trong Rust.

2. Phần viết bằng Python, trong file defity/__init__.py.

Thông thường, phần Rust phía trên là đủ rồi. Nhưng mình có những ý đồ thêm mà không tiện hiện thực hóa trong phần Rust phía trên nên mình viết ở trong đây. Các hàm trong đây sẽ là hàm được phơi ra cho người viết ứng dụng, sau đó nó sẽ thực hiện một vài bước chuyển đổi, rồi gọi sang các hàm Rust phía trên. Ý đồ đâu tiên là mình muốn thêm type hint (chú thích) để giúp code dễ đoán cho người sử dụng thư viện. Ví dụ:

def from_file(file: Union[Path, str, IO]) -> str:

Hiện tại, type hint chưa được hỗ trợ đầy đủ trong C-API của Python, nên nếu đưa vào phần Rust phía trên cũng không ích lợi gì nhiều. Nhìn vào type hint, có thể thấy from_file nhận đầu vào thuộc 3 kiểu: Path, str, IO, trong đó Path, str ứng với đường dẫn file, IO ứng với file object. Như thế người dùng thư viện có thể dùng như sau:

import defity

with open('path/to/landscape.png', 'rb') as f:
  defity.from_file(f)

Việc thấu hiểu đặc tính của từng ngôn ngữ để thiết kế được hàm sao cho tiện dùng, phát huy được ưu điểm của ngôn ngữ là một kỹ năng cần có nếu bạn muốn dấn thân vào con đường sáng tạo thư viện.

Phần này cũng phụ trách xử lý các kiểu dữ liệu điển hình trong Python, chuyển sang các kiểu đon giản hơn, rồi mới gọi hàm bên phía Rust. Ví dụ, hàm from_file ở đây là

def from_file(file: Union[Path, str, IO]) -> str:

nhưng phiên bản tương ứng bên code Rust (src/lib.rs) chỉ là

fn from_file(py: Python, path: PathBuf) -> PyResult<String>

tức là không nhận file object.

Có thể bạn sẽ thắc mắc, tại sao không để hàm phía Rust nhận file object luôn. Câu trả lời là, vì mình muốn hàm bên phía Rust không cần nắm giữ Global Interpreter Lock (GIL) của CPython, để giúp phía ứng dụng thoải mái chạy trong chế độ multi-threading. “File object” là kiểu dữ liệu của riêng Python nên hàm Rust muốn nhào nặn gì nó là phải nắm giữ GIL, khi đó nếu có thread nào đang có hành động cần đến GIL, nó sẽ phải tạm dừng, làm giảm ích lợi của multi-threading đi.

Phát hành

Defity được viết bằng ngôn ngữ biên dịch nên khi để sử dụng được nó, phải qua quá trình biên dịch thành file *.so. Thông thường các thư viện mã nguồn mở sẽ phát hành ở dạng mã nguồn. Khi người dùng cài thì chương trình quản lý gói (package manager) sẽ tự động làm bước biên dịch trên máy người dùng luôn. Điều náy sẽ tạo gánh nặng cho người dùng vì họ sẽ phải cài bộ công cụ biên dịch Rust trước. Thật may là Python có đề ra chuẩn để cho phép tác giả phân phối các gói thư viện build sẵn ở dạng binary, cụ thể là file wheel. Khi người dùng cài thư viện bằng pip, pip sẽ kiểm tra máy người dùng là nền tảng gì (hệ điều hành, vi xử lý gì) rồi tải file wheel tương ứng cho nền tảng đó để cài, không phải trải qua bước build. Vì mình cũng có kinh nghiệm về các board Linux nhúng (BeagleBone, Raspberry Pi) nên mình rất quan tâm tới việc build sẵn cho các nền tảng này. Điểm thiệt thòi cho các board nhúng này là vi xử lý yếu (ARM) mà trình biên dịch Rust thì lại chạy rất nặng (vì nó phải thực hiện việc kiểm tra chặt chẽ, chi tiết hơn các ngôn ngữ khác), nên bắt người dùng phải build thì tội cho họ quá. Thế là mình huy động các board Raspberry Pi mà mình có ra, để build cho các nền tảng như sau:

  • Python từ 3.6 đến 3.10.
  • Linux trên x86, 64 bit.
  • Linux trên ARMv7, 32 bit
  • Linux trên ARMv8, 64 bit.
  • Windows trên x86
  • MacOS trên x86

Trong đó bản cho Windows và MacOS build được là nhờ tận dụng GitHub Action, chứ mình cũng chẳng có máy Windows lẫn MacOS để mà tự build.

Rasp

Các file wheel trên có thể tìm thấy trên PyPI: https://pypi.org/project/defity/#files

Danh sách kia thiếu ARMv6 (dùng trong Pi Zero và Pi đời đầu) vì con Raspberry Pi ARMv6 mà mình có hơi yếu, lại đang mắc làm nhiệm vụ khác, nên sức CPU còn lại build không nổi.

Để build cho các kiến trúc vi xử lý khác, thực ra không cần thiết bị thật mà có thể cross-build từ trên máy x86 luôn. Nhưng mình chọn build trên thiết bị thật cho… ngầu. Khi nào cần build cho các vi xử lý mà thiết bị thật yếu quá, ví dụ build cho MIPS (hay dùng trong các router wifi) thì mới còn lựa chọn duy nhất là cross-build, vì các router của mình quá yếu, thậm chí còn không có chỗ để cài trình biên dịch.

Bài viết gốc được đăng tải tại quan.hoabinh.vn

Xem thêm:

Tìm việc làm Python đãi ngộ hấp dẫn trên TopDev

RELATED ARTICLESMORE FROM AUTHOR