أين في الظاهري ، يذهب الرمز المخصص؟

Question

أي نوع من بنية الدليل يجب أن يتبعه أحد عند استخدامه virtualenv؟ على سبيل المثال ، إذا كنت أقوم ببناء تطبيق WSGI وأنشأت افتراضية تسمى foobar سأبدأ بهيكل الدليل مثل:

/foobar
  /bin
    {activate, activate.py, easy_install, python}
  /include
    {python2.6/...}
  /lib
    {python2.6/...}

بمجرد إنشاء هذه البيئة ، أين يمكن أن يضع أحدهم:

• ملفات بيثون؟
• ملفات ثابتة (الصور/الخ)؟
• الحزم "المخصصة" ، مثل تلك المتاحة على الإنترنت ولكن لم يتم العثور عليها في متجر الجبن؟

في ما يتعلق virtualenv الدلائل؟

(افترض أنني أعرف بالفعل حيث يجب أن تذهب أدلة VirtualEnv نفسها.)

Answer 1

virtualenv يوفر مثيل مترجم Python ، وليس مثيل تطبيق. لن تقوم عادة بإنشاء ملفات التطبيق الخاصة بك ضمن الدلائل التي تحتوي على بيثون الافتراضي للنظام ، وبالمثل ، لا يوجد أي شرط لتحديد موقع التطبيق الخاص بك ضمن دليل VirtualEnV.

على سبيل المثال ، قد يكون لديك مشروع لديك تطبيقات متعددة باستخدام نفس VirtualEnV. أو ، قد تختبر تطبيقًا باستخدام VirtualEnv سيتم نشره لاحقًا باستخدام Python نظام. أو ، قد تقوم بتعبئة تطبيق مستقل حيث قد يكون من المنطقي وجود دليل VirtualEnV في مكان ما داخل دليل التطبيق نفسه.

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

Answer 2

إذا كان لديك عدد قليل من المشاريع فقط في كثير من الأحيان ، لا شيء يمنعك من إنشاء VirtualEnV جديد لكل مشاريع ، ووضع حزمك في الداخل:

/foobar
  /bin
    {activate, activate.py, easy_install, python}
  /include
    {python2.6/...}
  /lib
    {python2.6/...}
  /mypackage1
    __init__.py
  /mypackage2
    __init__.py

ميزة هذا النهج هي أنه يمكنك دائمًا التأكد من العثور على البرنامج النصي المنشط الذي ينتمي إلى المشروع في الداخل.

$ cd /foobar
$ source bin/activate
$ python 
>>> import mypackage1
>>>

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

  /virtualenvs
    /foobar
      /bin
        {activate, activate.py, easy_install, python}
      /include
        {python2.6/...}
      /lib
        {python2.6/...}
  /foobar
    /mypackage1
      __init__.py
    /mypackage2
      __init__.py

وبهذه الطريقة ، يمكنك دائمًا البدء من جديد مع VirtualEnv جديد عندما تسوء الأمور ، وتبقى ملفات مشروعك آمنة.

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

$ cd /foobar
$ source ../virtualenvs/foobar/bin/activate
$ python 
>>> import mypackage2
>>>

بالنسبة للمستخدمين الذين يتعين عليهم بانتظام إعداد وهدم VirtualEnvs ، سيكون من المنطقي أن ننظر إلى VirtualEnvwrapper.

http://pypi.python.org/pypi/virtualenvwrapper

مع VirtualEnvwrapper يمكنك

* create and delete virtual environments

* organize virtual environments in a central place

* easily switch between environments

لا داعي للقلق أكثر من مكان ظاهرك الافتراضي عند العمل في المشاريع "Foo" و "Bar":

  /foo
    /mypackage1
      __init__.py
  /bar
    /mypackage2
      __init__.py

هذه هي الطريقة التي تبدأ بها العمل على مشروع "فو":

$ cd foo
$ workon
bar
foo
$ workon foo
(foo)$ python
>>> import mypackage1
>>>

ثم التبديل إلى مشروع "شريط" بسيط مثل هذا:

$ cd ../bar
$ workon bar
(bar)$ python
>>> import mypackage2
>>>

أنيق جدا ، أليس كذلك؟

Answer 3

نظرًا لأن VirtualEnVs غير قابلة للانتقال ، في رأيي ، من الممارسات السيئة وضع ملفات مشروعك داخل دليل VirtualEnV. VirtualEnv نفسها هي قطعة أثرية تنمية/نشر تم إنشاؤها (نوع من ملف .pyc) ، وليس جزءًا من المشروع ؛ يجب أن يكون من السهل تفجيرها وإعادة إنشائها في أي وقت ، أو إنشاء واحد جديد على مضيف نشر جديد ، إلخ.

كثير من الناس في الواقع يستخدمون VirtualEnvwrapper, ، الذي يزيل الافتراضية الفعلية من وعيك بالكامل تقريبًا ، مما يضعها جميعها جنبًا إلى جنب في $ home/.virtualenvs بشكل افتراضي.

Answer 4

إذا أعطيت مشروعك أ setup.py, ، يمكن لـ PIP استيرادها من التحكم في الإصدار مباشرة.

افعل شيئًا كهذا:

$ virtualenv --no-site-packages myproject
$ . myproject/bin/activate
$ easy_install pip
$ pip install -e hg+http://bitbucket.org/owner/myproject#egg=proj

ال -e سوف يضع المشروع في myproject/src, ، لكن ربطه بـ myproject/lib/pythonX.X/site-packages/, ، لذلك سيتم التقاط أي تغييرات تقوم بإجراءها فورًا في وحدات تستوردها من محليك site-packages. ال #egg يخبر بت PIP ما الاسم الذي تريد إعطائه لحزمة البيض التي ينشئها لك.

إذا لم تستخدم --no-site-packages, ، احرص على تحديد أنك تريد تثبيت PIP في VirtualEnV مع -E اختيار