Vấn đề Namespace phẳng của Rust gây tranh luận trong cộng đồng về các giải pháp quản lý package

Cộng đồng lập trình Rust đang vật lộn với một vấn đề ngày càng nghiêm trọng khiến các nhà phát triển bối rối: xung đột tên package và các crate bị bỏ hoang. Khi các thư viện phổ biến bị fork do các vấn đề bảo trì, người dùng phải đối mặt với những lựa chọn khó hiểu giữa nhiều phiên bản có tên tương tự, dẫn đến việc phân mảnh nỗ lực phát triển và lãng phí tài nguyên.

Ví dụ về các gói Rust bị ảnh hưởng:

• ffmpeg → ffmpeg-next → ffmpeg-the-third, rffmpeg
• spectral → speculoos
• onnxruntime-rs → ort
• leaf → juice
• yaml-rust → yaml-rust2
• serde-yaml → serde-yaml-bw

Nguyên nhân gốc rễ: Thiết kế Namespace phẳng

Trọng tâm của vấn đề này nằm ở hệ thống namespace phẳng của Rust trên crates.io, nơi mỗi tên package phải là duy nhất trên toàn bộ registry. Điều này tạo ra tình huống ai đến trước được phục vụ trước, nơi những người dùng sớm có thể kiểm soát hiệu quả các tên package ngay cả sau khi bỏ hoang dự án của họ. Các thành viên cộng đồng chỉ ra rằng điều này khác biệt đáng kể so với các ngôn ngữ hiện đại khác sử dụng hệ thống đặt tên phân cấp.

Cách tiếp cận của Go cung cấp một giải pháp thay thế hấp dẫn, nơi các package được xác định bằng đường dẫn import đầy đủ như github.com/user/package-name. Điều này có nghĩa là nhiều nhà phát triển có thể tạo các package với cùng tên cơ sở dưới các đường dẫn khác nhau, loại bỏ hoàn toàn xung đột namespace. Khi một package bị bỏ hoang, các fork có thể duy trì tên gốc trong khi chỉ cần thay đổi đường dẫn import.

Các giải pháp tạm thời kỹ thuật và hạn chế

Mặc dù Rust có hỗ trợ một số giải pháp thay thế cho namespace phẳng thông qua các dependency dựa trên git và các registry thay thế, những giải pháp này có những hạn chế thực tế. Các nhà phát triển có thể chỉ định các dependency trực tiếp từ các repository git hoặc sử dụng các registry tùy chỉnh, nhưng các crate được xuất bản trên crates.io không thể phụ thuộc vào các package từ các registry khác. Hạn chế này giữ cho hầu hết hệ sinh thái bị ràng buộc với các ràng buộc đặt tên của registry chính.

Cộng đồng cũng đã thảo luận về các cơ chế thay thế nguồn cho phép người dùng downstream thay thế các nguồn package, nhưng những điều này yêu cầu cấu hình bổ sung và không giải quyết được vấn đề khả năng khám phá cơ bản.

Học hỏi từ các hệ sinh thái khác

Cách tiếp cận của hệ sinh thái Java Maven sử dụng các định danh nhóm, định danh artifact và classifier cung cấp một mô hình khác cho việc đặt tên package phân cấp. Hệ thống này, đã được chứng minh qua nhiều thập kỷ, ngăn chặn các xung đột namespace gây khó khăn cho các sơ đồ đặt tên phẳng. Một số thành viên cộng đồng lưu ý rằng những cách tiếp cận kiểu cũ này từ Java và .NET chứa đựng những bài học có giá trị cho các hệ sinh thái ngôn ngữ mới hơn.

Giá như các ngôn ngữ mới hơn đã theo cách kiểu cũ của Java Maven với bộ ba: groupId, artifactId và classifier cho các thư viện. Những vấn đề này đơn giản sẽ không tồn tại.

So sánh các Hệ thống Đặt tên Thay thế:

Con đường phía trước

Trong khi các giải pháp tổ chức như các tổ chức GitHub được cộng đồng quản lý của Julia cung cấp một số sự cứu trợ, chúng không giải quyết được các ràng buộc kỹ thuật cơ bản của hệ thống package của Rust. Cuộc thảo luận làm nổi bật nhu cầu về những thay đổi cơ bản hơn trong cách Rust xử lý việc đặt tên package và quản lý dependency.

Cuộc tranh luận tiếp tục khi cộng đồng cân nhắc lợi ích của việc duy trì tính tương thích với hệ sinh thái hiện tại so với những ưu điểm của việc áp dụng các sơ đồ đặt tên linh hoạt hơn. Cho đến lúc đó, các nhà phát triển phải điều hướng những hạn chế của hệ thống hiện tại trong khi hy vọng về những cải tiến trong tương lai cho kiến trúc của crates.io.

Tham khảo: What Julia has that Rust desperately needs