Mã tùy chỉnh đi đâu trong virtualenv?

Loại cấu trúc thư mục nào nên tuân theo khi sử dụng virtualenv? Ví dụ: nếu tôi đang xây dựng một ứng dụng WSGI và tạo một virtualenv có tên là foobartôi sẽ bắt đầu với cấu trúc thư mục như:

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

Sau khi môi trường này được tạo, người ta sẽ đặt ở đâu:

• tệp python?
• tệp tĩnh (hình ảnh / v.v.)?
• gói "tùy chỉnh", chẳng hạn như gói có sẵn trực tuyến nhưng không được tìm thấy trong cửa hàng phô mai?

liên quan đến các virtualenvthư mục?

(Giả sử tôi đã biết bản thân các thư mục virtualenv sẽ đi đâu .)

virtualenvcung cấp một phiên bản thông dịch python, không phải một phiên bản ứng dụng. Thông thường, bạn sẽ không tạo các tệp ứng dụng của mình trong các thư mục chứa Python mặc định của hệ thống, tương tự như vậy, không có yêu cầu xác định vị trí ứng dụng của bạn trong một thư mục virtualenv.

Ví dụ: bạn có thể có một dự án mà bạn có nhiều ứng dụng sử dụng cùng một virtualenv. Hoặc, bạn có thể đang thử nghiệm một ứng dụng với virtualenv mà sau này sẽ được triển khai với Python hệ thống. Hoặc, bạn có thể đang đóng gói một ứng dụng độc lập, nơi bạn có thể đặt thư mục virtualenv ở đâu đó trong chính thư mục ứng dụng.

Vì vậy, nói chung, tôi không nghĩ rằng có một câu trả lời đúng cho câu hỏi. Và, một điều tốt virtualenvlà nó hỗ trợ nhiều trường hợp sử dụng khác nhau: không cần phải có một cách đúng.

Nếu bạn chỉ có một vài dự án thường xuyên, không có gì ngăn bạn tạo một virtualenv mới cho mỗi dự án và đặt các gói của bạn ngay bên trong:

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

Ưu điểm của phương pháp này là bạn luôn có thể chắc chắn tìm thấy tập lệnh kích hoạt thuộc về dự án bên trong.

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

Nếu bạn quyết định có tổ chức hơn một chút, bạn nên cân nhắc việc đặt tất cả các virtualenv của mình vào một thư mục và đặt tên cho từng cái theo tên dự án bạn đang thực hiện.

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

Bằng cách này, bạn luôn có thể bắt đầu lại với virtualenv mới khi có sự cố và các tệp dự án của bạn vẫn an toàn.

Một lợi thế khác là một số dự án của bạn có thể sử dụng cùng một virtualenv, vì vậy bạn không cần phải thực hiện cài đặt lặp đi lặp lại cùng một lần nếu bạn có nhiều phụ thuộc.

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

Đối với những người dùng thường xuyên phải thiết lập và gỡ bỏ các virtualenv, sẽ rất hợp lý khi nhìn vào virtualenvwrapper.

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

Với virtualenvwrapper, bạn có thể

* create and delete virtual environments

* organize virtual environments in a central place

* easily switch between environments

Bạn không còn phải lo lắng về vị trí các virtualenv của mình khi làm việc trên các dự án "foo" và "bar":

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

Đây là cách bạn bắt đầu làm việc với dự án "foo":

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

Sau đó, chuyển sang "thanh" của dự án đơn giản như sau:

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

Khá gọn gàng phải không?

Bởi vì virtualenv không thể di dời, theo ý kiến ​​của tôi, việc đặt các tệp dự án của bạn bên trong thư mục virtualenv là một cách làm không tốt. Bản thân virtualenv là một tạo tác phát triển / triển khai được tạo (giống như tệp .pyc), không phải là một phần của dự án; sẽ dễ dàng loại bỏ nó và tạo lại nó bất cứ lúc nào hoặc tạo một cái mới trên một máy chủ triển khai mới, v.v.

Trên thực tế, nhiều người sử dụng virtualenvwrapper , công cụ này sẽ loại bỏ gần như hoàn toàn các virtualenv thực tế khỏi nhận thức của bạn, đặt tất cả chúng cạnh nhau trong $ HOME / .virtualenvs theo mặc định.

Nếu bạn cung cấp cho dự án của mình a setup.py, pip có thể nhập trực tiếp từ kiểm soát phiên bản.

Làm điều gì đó như sau:

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

Ý -echí sẽ đưa dự án vào myproject/src, nhưng liên kết với nó myproject/lib/pythonX.X/site-packages/, vì vậy bất kỳ thay đổi nào bạn thực hiện sẽ được chọn ngay lập tức trong các mô-đun nhập nó từ cục bộ của bạn site-packages. Các #eggchút nói pip gì tên bạn muốn cung cấp cho gói trứng nó tạo ra cho bạn.

Nếu bạn không sử dụng --no-site-packages, hãy cẩn thận chỉ định rằng bạn muốn cài đặt pip vào virtualenv với -Etùy chọn