Django و Virtualenv تطوير / أفضل الممارسات

Question

فضولي فقط كيف يقوم الناس بنشر مشاريع django الخاصة بهم بالاشتراك مع Virtualenv

• وبشكل أكثر تحديدا، كيف يمكنك الاحتفاظ بمزامنة إنتاجك Virtualenv بشكل صحيح باستخدام جهاز التطوير الخاص بك؟

يمكنني استخدام GIT for SCM ولكن ليس لدي virtualenv داخل repo git - هل يجب علي ذلك، أم أنه من الأفضل استخدام تجميد pip ثم إعادة إنشاء البيئة على الخادم باستخدام إخراج التجميد؟ (إذا قمت بذلك، هل يمكن أن تصف الخطوات - أنا أجد وثائق جيدة للغاية في عملية غير القمادة - هي شيء مثل pip install -r freeze_output.txt المستطاع؟)

Answer 1

أنا فقط اضبط شيء مثل هذا في العمل باستخدام PIP والنسيج وجيت. التدفق هو أساسا مثل هذا، والمقترض بشدة من هذا البرنامج النصي:

1. في شجرة المصدر الخاصة بنا، نحافظ على متطلبات ملف. سنحافظ على هذا يدويا.
2. عندما نقوم بإصدار جديد، فإن البرنامج النصي النسيج يخلق أرشيف يستند إلى أي شيء تركيه.
3. سوف يجد النسيج شا لما ننشأه git log -1 --format=format:%h TREEISH. وبعد هذا يعطينا SHA_OF_THE_RELEASE
4. سوف تحصل النسيج على آخر شا لملف المتطلبات لدينا git log -1 --format=format:%h SHA_OF_THE_RELEASE requirements.txt. وبعد هذا يبصق النسخة القصيرة من التجزئة، مثل 1d02afc وهو Sha لهذا الملف لهذا الإصدار بالذات.
5. سينظر البرنامج النصي للنسيج بعد ذلك إلى دليل يتم فيه تخزين Virtualenvs لدينا على المضيف البعيد (المضيفين).
   1. إذا لم يكن هناك دليل اسمه 1d02afc, ، يتم إنشاء VirtualEnv جديد وإعداده pip install -E /path/to/venv/1d02afc -r /path/to/requirements.txt
   2. إن كان هناك يكون موجود path/to/venv/1d02afc, ، لا شيء يتم

يمر الجزء السحري الصغير من هذا أيا كان الأشجار التي تريدها في git، ولديها التعبئة والتغليف (من النسيج). باستخدام git archive my-branch, git archive 1d02afc أو أي شيء آخر، أنا مضمون للحصول على الحزم المناسبة المثبتة على الأجهزة البعيدة الخاصة بي.

ذهبت هذا الطريق منذ أن كنت حقا لا أريد أن أحصل على virtuenvs إضافية تطفو إذا لم تتغير الحزم بين الإفراج. أنا أيضا لا أحب فكرة وجود الحزم الفعلية التي أعاك منها في شجرة المصدر الخاصة بي.

Answer 2

يمكنني استخدام هذا bootstrap.py: http://github.com/ccnmtl/ccnmtldjango/blob/master/ccnmtldjango/template/bootstrap.py.

الذي تتوقع هو دليل يسمى "المتطلبات" التي تبدو مثل هذا: http://github.com/ccnmtl/ccnmtldjango/tree/master/ccnmtldjango/template/requirements/

هناك applips.txt، libs.txt (أي apps.txt تتضمن - أنا فقط أحب أن أبقي تطبيقات django منفصلة من وحدات Python الأخرى) ودليل SRC الذي يحتوي على Tarballs الفعلي.

عندما يتم تشغيل bootstrap.py، يقوم بإنشاء VirtualEnv (مسح واحد سابق إذا كان موجودا) ويقوم بتثبيت كل شيء من المتطلبات / التطبيقات في ذلك. أنا لا أقوم بتثبيت أي شيء في virtualenv خلاف ذلك. إذا كنت ترغب في تضمين مكتبة جديدة، أضع Tarball في متطلبات / SRC /، أضف خطا إلى أحد TextFiles وإعادة تشغيله ./bootstrap.py.

يتم فحص bootstrap.py والمتطلبات في عنصر تحكم الإصدار (أيضا نسخة من pip.py لذلك لا بد لي حتى أن يكون لديك هذا النظام المثبت في أي مكان). virtualenv نفسه ليس كذلك. البرامج النصية التي لدي ذلك دفعت إلى تشغيل الإنتاج ./bootstrap.py على خادم الإنتاج في كل مرة أذهب إليها. (bootstrap.py يذهب أيضا إلى بعض الأطوال لضمان أن تلتصق بثثون 2.5 لأن هذا ما لدينا على خوادم الإنتاج (Ubuntu Hardy) وآلة Dev الخاصة بي (Ubuntu Karmic) الافتراضي إلى Python 2.6 إذا لم تكن حذرا)