لا تستخدم Ruby الافتراضي في macOS: البديل الصحيح لتطوير مشاريعك

لماذا لا ينبغي استخدام Ruby الافتراضي في macOS؟

قد تكون سمعت النصيحة التالية من قبل: لا تستخدم Ruby المدمج مع النظام. هذه النصيحة صحيحة جداً، خصوصاً إذا كنت تنوي تطوير تطبيقات أو العمل على مشاريع برمجية حقيقية. فرغم أن macOS يأتي مع نسخة مثبتة مسبقاً من Ruby، فإن هذه النسخة مخصصة لخدمة النظام نفسه وبعض أدواته الداخلية، وليست بيئة مناسبة لتطويرك اليومي.

بمعنى أوضح: يمكن استخدام Ruby المدمج لتشغيل بعض سكربتات الإدارة أو المهام البسيطة المرتبطة بالنظام، لكن لا يُنصح إطلاقاً بالاعتماد عليه في بناء التطبيقات أو تثبيت الحزم البرمجية أو إدارة المشاريع.

كيف تعرف أي نسخة Ruby لديك؟

يأتي macOS عادةً مع نسخة نظامية من Ruby مثبّتة مسبقاً. لمعرفة مسار النسخة الحالية، استخدم الأمر which ruby:

$ which ruby
/usr/bin/ruby

إذا ظهر لك المسار /usr/bin/ruby، فهذا يعني أنك تستخدم نسخة Ruby الافتراضية التابعة للنظام.

هذه النسخة ليست مشكلة بحد ذاتها، لكن المشكلة تبدأ عندما تحاول استخدامها في التطوير أو تعديلها عبر تثبيت الحزم أو تحديث بيئتها. هنا تظهر التعقيدات التقنية ومشكلات الصلاحيات.

ما الخيار الصحيح لتطوير مشاريع Ruby؟

إذا كنت تطور مشاريع باستخدام Ruby، فالأفضل أن تثبت نسخة مستقلة مخصصة للتطوير، وذلك بإحدى الطريقتين التاليتين:

• تثبيت Ruby عبر Homebrew.
• استخدام مدير إصدارات مثل asdf أو chruby أو rbenv أو rvm.

مدير الإصدارات مفيد جداً إذا كنت تعمل على أكثر من مشروع، خاصة عندما يحتاج كل مشروع إلى إصدار مختلف من Ruby. وبدلاً من تقييد نفسك بإصدار واحد على مستوى النظام، تستطيع التبديل بين الإصدارات بسهولة وبدون فوضى.

أبرز أسباب تجنب Ruby النظامي في Mac

1. صعوبات تثبيت الحزم Gems

تعتمد معظم مشاريع Ruby على مكتبات جاهزة تُعرف باسم RubyGems أو اختصاراً gems. هذه الحزم تجعل التطوير أسرع وأكثر مرونة، وغالباً لن تجد مشروعاً عملياً يخلو منها.

عند استخدام Ruby النظامي، فإن تنفيذ أمر مثل gem install سيحاول حفظ الحزم في مجلد تابع للنظام مثل /Library/Ruby/Gems/2.6.0. هذا المجلد مملوك للمستخدم الخارق root، ما يعني أن المستخدم العادي لا يملك صلاحية الكتابة فيه.

عند محاولة تثبيت حزمة مثل rails، ستظهر لك رسالة خطأ مشابهة للتالي:

ERROR: While executing gem ... (Gem::FilePermissionError)
You don't have write permissions for the /Library/Ruby/Gems/2.6.0 directory

هذه المشكلة ليست عرضية، بل هي نتيجة مباشرة لطبيعة حماية النظام وكون هذه البيئة غير مخصصة للاستخدام التطويري.

2. استخدام sudo يعرّض النظام للمخاطر

قد يظن البعض أن الحل بسيط: استخدام sudo لتجاوز مشكلة الصلاحيات. مثال ذلك:

$ sudo gem install rails

لكن هذا الحل سيئ تقنياً وأمنياً. فعندما تستخدم sudo هنا، فأنت تمنح أمر التثبيت صلاحيات كاملة لتعديل ملفات النظام. وهذا قد يؤدي إلى:

• إفساد ملفات مهمة يعتمد عليها macOS.
• إدخال تغييرات يصعب التراجع عنها لاحقاً.
• توسيع أثر أي حزمة غير موثوقة أو تحتوي على تعليمات ضارة.
• خلق تضارب بين بيئة النظام وبيئة التطوير.

القاعدة الذهبية هنا: إذا كنت تحتاج إلى sudo لتثبيت حزم تطوير عادية، فغالباً أنت تستخدم البيئة الخطأ.

3. فوضى إدارة الحزم والاعتماديات

المطورون المحترفون لا يثبتون الحزم بشكل عشوائي، بل يعتمدون على أداة Bundler لإدارة الاعتماديات داخل كل مشروع. تستخدم Bundler ملفاً باسم Gemfile لتحديد الحزم المطلوبة وإصداراتها.

تكمن أهمية ذلك في أن مشروعاً قد يحتاج إلى إصدار معين من حزمة ما، بينما يحتاج مشروع آخر إلى إصدار مختلف. كما قد تعتمد حزمتان داخل المشروع نفسه على إصدارات متباينة من مكتبة فرعية مشتركة.

إذا استخدمت Ruby النظامي مع تثبيت الحزم عبر sudo، فستنتهي غالباً إلى بيئة مزدحمة بإصدارات متعارضة ومكتبات مختلطة داخل مجلد النظام. هذا النوع من الفوضى يجعل الصيانة أصعب، ويزيد احتمال تعطل المشاريع أو ظهور أخطاء يصعب تتبعها.

صحيح أنه توجد حلول جزئية لتثبيت Bundler داخل مجلد المستخدم، لكن الحل الأبسط والأكثر احترافية هو استخدام نسخة Ruby مستقلة عبر Homebrew أو عبر مدير إصدارات، بحيث تكون بيئة التطوير معزولة وواضحة.

4. نسخة النظام غالباً قديمة

من أهم أسباب تجنب Ruby الافتراضي في macOS أنه يكون غالباً متأخراً عن الإصدارات الحديثة. وقت كتابة المقال الأصلي، كانت النسخة الحديثة هي Ruby 3.0، بينما كانت النسخة المدمجة في macOS Catalina وBig Sur هي Ruby 2.6.3.

استخدام إصدار قديم يعني عملياً:

• فقدان التحسينات الحديثة في الأداء.
• عدم الاستفادة من الميزات اللغوية الجديدة.
• احتمال ضعف التوافق مع بعض الأدوات والمكتبات الحديثة.
• زيادة فرص مواجهة مشاكل دعم أو توثيق منتهي الصلاحية.

عند بدء مشروع جديد، من الأفضل اعتماد إصدار حديث ومستقر من Ruby. هذا يمنحك بيئة أكثر توافقاً مع الأدوات الحالية، ويقلل المشكلات المستقبلية.

ماذا تغيّر في الإصدارات الحديثة من macOS؟

أوضحت Apple أن لغات السكربت مثل Python وRuby وPerl كانت موجودة في macOS لأسباب تتعلق بالتوافق مع البرامج القديمة. لكنها أشارت أيضاً إلى أن الإصدارات المستقبلية من النظام قد لا تتضمن هذه البيئات بشكل افتراضي، وقد يحتاج المستخدم إلى تثبيت حزم إضافية بنفسه.

هذا يعني أن الاعتماد على Ruby النظامي ليس فقط خياراً غير مناسب حالياً، بل هو أيضاً خيار غير مضمون على المدى البعيد. لذلك، من الأفضل من الآن إعداد بيئة مستقلة خاصة بك بدلاً من ربط عملك بمكوّن قد يختفي أو يتغير سلوكه لاحقاً.

متى تستخدم Homebrew ومتى تستخدم مدير الإصدارات؟

استخدام Homebrew

إذا كنت مبتدئاً أو تعمل على مشروع واحد فقط، فإن تثبيت Ruby بواسطة Homebrew قد يكون خياراً ممتازاً. فهو بسيط، مباشر، ويمنحك نسخة حديثة بعيداً عن ملفات النظام.

استخدام مدير الإصدارات

أما إذا كنت تدير أكثر من مشروع، أو تحتاج إلى التنقل بين إصدارات متعددة، فإن مدير الإصدارات يصبح الخيار الأفضل. من خلال أدوات مثل rbenv أو asdf يمكنك تخصيص إصدار Ruby لكل مشروع على حدة، دون تعارض.

هذه المرونة مهمة جداً في بيئات العمل الاحترافية، حيث قد تعمل على مشروع حديث يعتمد على إصدار جديد، وآخر قديم يحتاج إلى إصدار مختلف تماماً.

أفضل ممارسة لبناء بيئة Ruby نظيفة على Mac

1. لا تعدّل نسخة Ruby المرفقة مع النظام.
2. لا تستخدم sudo gem install لتثبيت الحزم التطويرية.
3. ثبّت نسخة مستقلة من Ruby عبر Homebrew أو مدير إصدارات.
4. استخدم Bundler وملف Gemfile لإدارة الاعتماديات.
5. اختر إصداراً حديثاً ومستقراً يناسب مشروعك.
6. اجعل لكل مشروع بيئته الخاصة متى أمكن.

لمن يطوّر تطبيقات Rails

إذا كنت تنوي بناء تطبيقات ويب باستخدام Rails، فإن إعداد بيئة Ruby الصحيحة من البداية سيوفر عليك كثيراً من الوقت والمشكلات. فإطار Rails يعتمد بشكل كبير على الحزم والإصدارات المتوافقة، وأي خلل في إدارة البيئة قد ينعكس مباشرة على عملية التثبيت والتشغيل والتحديث.

لهذا السبب، ينصح دائماً بتجهيز بيئة تطوير مستقلة وقابلة للإدارة، خصوصاً إذا كان مشروعك يتضمن أدوات إضافية مثل Node.js أو سلاسل بناء حديثة للواجهة الأمامية.

مقارنة سريعة بين Ruby النظامي وRuby المخصص للتطوير

الخلاصة التقنية

الاعتماد على Ruby الافتراضي في macOS قد يبدو مريحاً في البداية، لكنه خيار غير مناسب لتطوير البرمجيات بشكل احترافي. مشكلات الصلاحيات، وخطر استخدام sudo، وفوضى الاعتماديات، وتقادم الإصدارات، كلها أسباب كافية للانتقال إلى بيئة مستقلة. من الناحية التقنية، أفضل قرار هو تثبيت نسخة حديثة من Ruby عبر Homebrew أو استخدام مدير إصدارات يمنحك عزلاً كاملاً ومرونة أعلى في إدارة المشاريع. باختصار: Ruby النظامي هو للنظام، أما نسخة التطوير فهي لك ولمشاريعك.