Python in a box-Python 3.3のvenv

確かに、Pythonアプリケーションを開発またはデプロイする人のほとんどは仮想環境を使用します。 特に、Ian Bickingによって書かれたvirtualenvを通じて。



このアイデアは非常に優れており、広く普及していることが判明したため、Python 3.3にはvenvモジュールとして類似したものがすぐに使用できます。 これは、virtualenvとほとんど同じですが、わずかに優れています。

どのように機能しますか？

venvの主な違いは、インタープリターに組み込まれており、システムモジュールをロードする前でも機能することです。 これを行うには、ライブラリを使用してベースディレクトリを決定するときに、およそ次のアルゴリズムが使用されます。

• インタープリター以上のディレクトリで、 pyvenv.cfg
  
  
  
  という名前のファイルpyvenv.cfg
  
  
  
  ます。
• ファイルが見つかった場合、キーホームを検索します。その値はベースディレクトリになります。
• ベースディレクトリで、システムライブラリが検索されています（特別なマーカーos.py
  
  
  
  により）。
• 何かがうまくいかなかった場合-すべてがバイナリにハードコードされた値にロールバックします。

これがvenvのポイントです。他のすべてはすでにそのラッパーです。

作成方法

すべてが非常に簡単です。- -m



venv



を使用してvenv



モジュールを呼び出すか、組み込みのpyvenvスクリプトを使用する必要があります。

 pyvenv /path/to/new/venv
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

スクリプトは、必要に応じて、指定されたディレクトリとすべての親ディレクトリを作成し、仮想環境を構築します。 これはWindowsでも実行できますが、呼び出しはもう少し冗長になります。

 c:\Python33\python -m venv /path/to/new/venv
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

作成時に、システムサイトパッケージの有効化、インタープリターのコピーの代わりにシンボリックリンクの使用など、さまざまなパラメーターを追加できます。



virtualenvとは異なり、新しいvenvでは、作成されるディレクトリが存在しないか空である必要があります。 これはおそらく、既存のファイルとの競合を防ぐために行われます。 これはPython 3.3のバグで、3.4ですでに修正されています。 （ありがとう、 svetlov ）。

使い方は？

bin / activate（windowsのScripts / activate）を介して古き良きアクティベーション方法を使用できます：

 cd /path/to/new/venv . bin/activate python3 some_script.py
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、あなたはそれを使用することはできません 、環境からインタプリタを呼び出すだけで 、すべてが自動的に動作します：

 /path/to/new/venv/bin/python3 some_script.py
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もちろん、これは#!/usr/bin/env python3



を介して直接実行されるスクリプトでは機能しません#!/usr/bin/env python3



それらの場合、以前と同様にアクティベーションを行う必要があります。 解決策があります-それについてもう少し。

更新する

システムでpythonバージョンが更新された場合、仮想環境も更新する必要がある場合があります。

それは簡単です-環境を作成するのと同じ方法でvenvを呼び出し、-- --upgrade



追加し--upgrade



：

 pyvenv --upgrade /path/to/new/venv
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、シンボリックリンクを使用すると自動的に行われますが、分離に加えてPythonバージョンとライブラリをコミットする場合は、手動で更新することをお勧めします。

EnvBuilder拡張機能

環境の作成に関するすべての作業は、 venv.EnvBuilder



クラスにvenv.EnvBuilder



。このクラスは、拡張できるように作成されています。



たとえば、環境を初期化するときに、 pip



からdistribute



、 pip



、および必要な初期依存関係をrequirements.txt



ます。 buildoutやmakeなど、より適切なツールの良心にもっと複雑なロジックを残した方が良いですが、初期構成はEnvBuilderレベルでも実行できます。



環境を作成するとき、 create(self, env_dir)



メソッドが使用されます。 元のクラスでは次のようになります。

  def create(self, env_dir): env_dir = os.path.abspath(env_dir) context = self.ensure_directories(env_dir) self.create_configuration(context) self.setup_python(context) if not self.upgrade: self.setup_scripts(context) self.post_setup(context)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このメソッドは、プロセス全体の本質を説明します。ディレクトリの作成（ ensure_directories



）、設定（ create_configuration



）、Pythonバイナリの追加（ setup_python



）、アクティベーションスクリプトの追加（ setup_scripts



）。



最後に、アクションを追加できるpost_setup



フックがpost_setup



れます。 post_setup



は、環境の作成時にのみ実行され、 upgrade



では実行されないことがpost_setup



upgrade



。 これは別のフックを追加することで簡単に修正できます。

 class ImprovedEnvBuilder(venv.EnvBuilder): def create(self, env_dir): """Overwrite create method (add more hooks)""" env_dir = path.abspath(env_dir) context = self.ensure_directories(env_dir) self.create_configuration(context) self.setup_python(context) if not self.upgrade: self.setup_scripts(context) self.post_setup(context) else: self.post_upgrade(context) def post_upgrade(self, context): pass
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ensure_directories



後にメソッドを呼び出す際のパラメータとして、 context



が渡されます-作成される環境に関するすべての必要な情報を属性の形式で含むオブジェクト。 何らかの理由で、これらのキーはまだドキュメントに記載されていませんが、基本クラスのensure_directories



メソッドのコードを見れば、自分ですべてを簡単に理解できます。 最も有用な属性を示します。

• context.bin_path-バイナリと実行可能スクリプトを含むディレクトリへのパス、
• context.env_dir-作成された環境があるディレクトリへのパス、
• context.env_exe-環境内のバイナリへのパス。

したがって、環境内でpythonスクリプトを実行するには、次のようにします。

 import subprocess import venv class MyEnvBuilder(venv.EnvBuilder): def post_setup(self, context): script = '/path/to/some_script.py' subprocess.call([context.env_exe, script])
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

venv内の実行可能スクリプト

仮想環境内の実行可能スクリプトの問題に戻りましょう。



virtualenvでは、 #/usr/bin/env python3



インタープリターを指定し、使用することを忘れずに使用するだけで十分です. bin/activate



. bin/activate



このアプローチが適している場合は、引き続きvenv



使用できます。



新しい方法があります。 EnvBuilder内では、 install_scripts(self, context, path)



メソッドが実装され、作成された環境へのスクリプトとバイナリのコピーが自動化されます。 path



は、サブディレクトリ「common」、「nt」、「posix」などのディレクトリにパスを渡す必要があります。 次に、必要なスクリプトまたはバイナリをサブディレクトリに配置します。 すべてのプラットフォームの「共通」スクリプト、「nt」-Windows、「posix」-Linux、Mac OS X、およびその他のposixシステム。



さらに、値の設定はテキストファイルに対して実行されます。 すぐに使用できます：

• __VENV_DIR__
  
  
  
  
• __VENV_NAME__
  
  
  
  
• __VENV_BIN_NAME__
  
  
  
  
• __VENV_PYTHON__
  
  
  
  

実行するpythonスクリプトのテンプレートの例：

 #!__VENV_PYTHON__ import sys import my_module if __name__ == '__main__': sys.exit(my_module.run(sys.argv))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

__VENV_PYTHON__



は、仮想環境でのPythonインタープリターへのフルパスに置き換えられます。



install_scripts



を使用してこのようなスクリプトをインストールした後、bin / activateを使用して環境をアクティブ化する必要なく起動できます。

...

• Venvモジュールのドキュメント
• PEP-405-Python仮想環境
• githubの小さなリポジトリで、distribute、pip、requirements.txtからの依存関係のリスト、および実行可能なスクリプトのセットを自動的にインストールすることでEnvBuilderアドオンの例を作成しました。