Özel kod bir virtualenv'de nereye gider?

Kullanılırken ne tür bir dizin yapısı izlenmelidir virtualenv? Örneğin, bir WSGI uygulaması oluşturuyorsam ve adında bir virtualenv oluştursaydım, foobarşöyle bir dizin yapısıyla başlardım:

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

Bu ortam oluşturulduktan sonra, biri kendi başına nereye yerleştirilir:

• python dosyaları?
• statik dosyalar (resimler / vb.)?
• İnternette bulunabilen ancak peynirci dükkanında bulunmayanlar gibi "özel" paketler?

ile ilgili olarak virtualenvdizinleri?

( Virtualenv dizinlerinin nereye gitmesi gerektiğini zaten bildiğimi varsayın .)

virtualenvbir uygulama örneği değil, bir python yorumlayıcı örneği sağlar. Normalde uygulama dosyalarınızı sistemin varsayılan Python'unu içeren dizinlerde oluşturmazsınız, aynı şekilde uygulamanızı bir virtualenv dizini içinde bulmanız gerekmez.

Örneğin, aynı virtualenv'i kullanan birden çok uygulamanızın olduğu bir projeniz olabilir. Veya, daha sonra bir Python sistemiyle konuşlandırılacak olan bir virtualenv ile bir uygulamayı test ediyor olabilirsiniz. Veya, virtualenv dizininin uygulama dizininin içinde bir yere yerleştirilmesinin mantıklı olabileceği bağımsız bir uygulamayı paketliyor olabilirsiniz.

Yani genel olarak sorunun tek bir doğru cevabı olduğunu düşünmüyorum. Ve iyi bir şey virtualenv, birçok farklı kullanım durumunu desteklemesidir: tek bir doğru yol olmasına gerek yoktur.

Her seferinde yalnızca birkaç projeniz varsa, hiçbir şey sizi her biri için yeni bir sanal ortam oluşturmaktan ve paketlerinizi doğrudan içine koymaktan alıkoyamaz:

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

Bu yaklaşımın avantajı, içindeki projeye ait olan etkinleştirme komut dosyasını bulacağınızdan her zaman emin olabilmenizdir.

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

Biraz daha organize olmaya karar verirseniz, tüm sanal ortamlarınızı tek bir klasöre koymayı ve her birine üzerinde çalıştığınız projenin adını vermeyi düşünmelisiniz.

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

Bu şekilde, işler ters gittiğinde her zaman yeni bir virtualenv ile yeniden başlayabilirsiniz ve proje dosyalarınız güvende kalır.

Diğer bir avantaj ise, projelerinizin birçoğunun aynı virtualenv'i kullanabilmesidir, bu nedenle çok fazla bağımlılığınız varsa aynı kurulumu tekrar tekrar yapmanız gerekmez.

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

Düzenli olarak virtualenv'leri kurması ve sökmesi gereken kullanıcılar için virtualenvwrapper'a bakmak mantıklı olacaktır.

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

Virtualenvwrapper ile şunları yapabilirsiniz:

* create and delete virtual environments

* organize virtual environments in a central place

* easily switch between environments

Artık "foo" ve "bar" projeleri üzerinde çalışırken sanal ortamlarınızın nerede olduğu konusunda endişelenmenize gerek yok:

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

"Foo" projesi üzerinde çalışmaya şu şekilde başlarsınız:

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

Ardından "bar" projesine geçiş şu kadar basit:

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

Oldukça temiz, değil mi?

Virtualenv'ler yeniden konumlandırılamadığından, bence proje dosyalarınızı virtualenv dizini içine yerleştirmek kötü bir uygulamadır. Virtualenv'in kendisi, projenin bir parçası değil, oluşturulmuş bir geliştirme / dağıtım yapısıdır (bir çeşit .pyc dosyası gibi); herhangi bir zamanda onu uçurup yeniden oluşturmak veya yeni bir dağıtım ana bilgisayarında yeni bir tane oluşturmak vb. kolay olmalıdır.

Aslında kullanımı pek çok kişi virtualenvwrapper varsayılan olarak hepsini yan-yana $ HOME / .virtualenvs yerleştirerek, neredeyse tamamen farkındalık gerçek virtualenvs kaldırır.

Projenize bir verirseniz setup.py, pip onu doğrudan sürüm kontrolünden içe aktarabilir.

Bunun gibi bir şey yapın:

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

Bu -e, projeyi yerleştirecek myproject/src, ancak ona bağlanacak myproject/lib/pythonX.X/site-packages/, böylece yaptığınız herhangi bir değişiklik, onu yerelinizden içe aktaran modüllerde hemen alınacaktır site-packages. #eggBiraz bunu sizin için oluşturduğu yumurta paketine vermek istiyorum adının ne pip söyler.

Eğer kullanmıyorsanız --no-site-packages, sen pip ile virtualenv içine yüklemek istediğinizi belirtmek için dikkatli olmak -Eseçeneğiyle