Rust راهنمای بسته محموله را تغییر می دهد

تیم Rust’s Cargo استفاده از Cargo.lock را برای فایل‌های دارای باینری اما نه کتابخانه‌ها توصیه می‌کرد، اما اکنون می‌گوید بهترین کار را برای پروژه خود انجام دهید.

به جای تشویق توسعه دهندگان Rust به انجام Cargo.lock فایل برای بسته های دارای باینری اما نه کتابخانه، تیم Rust’s Cargo اکنون توصیه می‌کند برنامه‌نویسان بهترین کار را انجام دهند< /a> برای پروژه آنها. تغییر در راهنمایی‌ها، از تیم پشتیبان مدیر بسته Rust، با توجه به اینکه زبان Rust جریان اصلی‌تر شده است انجام می‌شود.

یک فایل قفل Cargo.lock برای توصیف وضعیت در زمان ساخت موفقیت آمیز در نظر گرفته شده است. در توصیه به افراد برای انجام بهترین کار برای پروژه، تیم همچنان پیشنهاد می کند که Cargo.lock را به عنوان نقطه شروع تصمیم گیری خود انجام دهند. فرمان cargo new دیگر Cargo.lock را برای کتابخانه ها نادیده نمی گیرد.

تیم Cargo آزمایش‌های منظم را تشویق می‌کند در برابر آخرین وابستگی ها. در بولتنی که در ۲۹ اوت منتشر شد، تیم Cargo گفت دستورالعمل‌های قدیمی تضمین می‌کرد که کتابخانه‌ها آخرین وابستگی‌های خود را آزمایش می‌کردند و با اطمینان از رفع سریع مشکلات، به‌ویژه سازگاری با عقب، به حفظ کیفیت بالا در اکوسیستم بسته Rust کمک می‌کردند. این تیم معتقد بود که به ترویج “فرهنگ کیفیت” در اکوسیستم نوپا کمک می کند.

اما نکات منفی نیز وجود داشته است، مانند حذف تاریخچه از پایه کد، دو نیم‌سازی برای یافتن علت اصلی یک اشکال برای نگهدارنده‌ها دشوارتر است. و سردرگمی می‌تواند برای مشارکت‌کنندگان، ناشی از یک CI نامطمئن (ادغام پیوسته) زمانی که یک وابستگی حذف می‌شود یا یک نسخه جدید دارای یک اشکال است، ایجاد شود. از زمانی که این دستورالعمل نوشته شد، Rust از زبانی برای پذیرندگان اولیه به یک جریان اصلی تبدیل شده است. باید تجربه حضوری توسعه دهندگان جدید Rust را در نظر داشت. پذیرش گسترده‌تر همچنین به این معنی است که فرض اینکه همه از آخرین نسخه Rust استفاده می‌کنند، همیشه عملی نیست.

به‌علاوه، اکوسیستم وسیع‌تر باعث شده است که راه‌اندازی و نگهداری CI آسان‌تر شود. محصولاتی مانند Dependabot و Renovate علاوه بر اینکه کنترل نسخه را برای آزمایش وابستگی های جدید نادیده می گیرد، گزینه هایی را باز کرده است. تیم Cargo اکنون بر این باور است که بهترین کار این است که انتخاب را به توسعه دهندگان واگذار کنیم و در عین حال اطلاعات مورد نیاز برای تصمیم گیری را در اختیار آنها قرار دهیم. برنامه‌نویسان می‌توانند بازخوردی درباره این خط‌مشی در GitHub ارائه دهند، یا می‌توانند با تیم باربری در Zulip.