仮想環境(7)

TOC

コンテナ技術を用いる仮想環境利用の考察

コンテナ技術を用いる仮想環境は、外部から導入するバイナリーを実行する 際のリスク低減とメインのシステムの環境コンタミを防ぐのには悪くないので しょう。そういった意味でtesting環境では安定しないオフィス関係のデスク トップアプリの安定版最新バージョンの導入や、Debianがまだ提供していない アップストリームの最新バージョンのアプリ導入に使うのはありがも知れません。

• AppImage
• Flatpack
• Snapcraft

ただ、単にパッケージ開発やビルド環境のためだけならLXC仮想環境をLXCの CLIから用いるのは面倒です。

最初の、仮想環境(1) の内容を見直してsbuild/schrootを経由した単純なchroot環境を使うようになり 益々そう感じます。

chrootにせよLXCにせよKernel以外のシステム全体のコピーを各環境毎に確保する ので重いことは否めません。

Python: venv + pip (manual)

Debianが提供しなくなったgripを、 PyPIからのPythonのモジュールとしてpipで導入すると、 すでにシステムに導入済みのPythonのモジュールまで、sudoしなかったので システムレベルでの/usr/local/の中への変更は無く、ユーザー環境の ~/.local/の中への変更のみとはいえ、そこに最新版を依存関係で導入したり するのが気になっていました。さすがにこれだけのためにchrootやコンテナ環境 を作るのは重いのでPython環境だけを仮想化しました。

gripをPython環境だけを仮想化して導入した ので、以下に例示します。

$ pip list --user

いま、ユーザー環境へのpipによるパッケージ導入はありません。

$ cd ~/bin
$ python3 -m venv venv
$ cd venv
$ source venv/bin/activate
(venv) $ pip install grip
Collecting grip
  Using cached grip-4.5.2-py3-none-any.whl
Collecting requests>=2.4.1
  Using cached requests-2.25.1-py2.py3-none-any.whl (61 kB)
Collecting path-and-address>=2.0.1
  Using cached path_and_address-2.0.1-py3-none-any.whl
Collecting Markdown>=2.5.1
  Using cached Markdown-3.3.4-py3-none-any.whl (97 kB)
Collecting Flask>=0.10.1
  Using cached Flask-2.0.1-py3-none-any.whl (94 kB)
Collecting docopt>=0.4.0
  Using cached docopt-0.6.2-py2.py3-none-any.whl
Collecting Pygments>=1.6
  Using cached Pygments-2.9.0-py3-none-any.whl (1.0 MB)
Collecting itsdangerous>=2.0
  Using cached itsdangerous-2.0.1-py3-none-any.whl (18 kB)
Collecting Werkzeug>=2.0
  Using cached Werkzeug-2.0.1-py3-none-any.whl (288 kB)
Collecting Jinja2>=3.0
  Using cached Jinja2-3.0.1-py3-none-any.whl (133 kB)
Collecting click>=7.1.2
  Using cached click-8.0.1-py3-none-any.whl (97 kB)
Collecting MarkupSafe>=2.0
  Using cached MarkupSafe-2.0.1-cp39-cp39-manylinux2010_x86_64.whl (30 kB)
Collecting idna<3,>=2.5
  Using cached idna-2.10-py2.py3-none-any.whl (58 kB)
Collecting certifi>=2017.4.17
  Using cached certifi-2021.5.30-py2.py3-none-any.whl (145 kB)
Collecting chardet<5,>=3.0.2
  Using cached chardet-4.0.0-py2.py3-none-any.whl (178 kB)
Collecting urllib3<1.27,>=1.21.1
  Using cached urllib3-1.26.5-py2.py3-none-any.whl (138 kB)
Installing collected packages: MarkupSafe, Werkzeug, urllib3, Jinja2, itsdangerous, idna, click, chardet, certifi, requests, Pygments, path-and-address, Markdown, Flask, docopt, grip
Successfully installed Flask-2.0.1 Jinja2-3.0.1 Markdown-3.3.4 MarkupSafe-2.0.1 Pygments-2.9.0 Werkzeug-2.0.1 certifi-2021.5.30 chardet-4.0.0 click-8.0.1 docopt-0.6.2 grip-4.5.2 idna-2.10 itsdangerous-2.0.1 path-and-address-2.0.1 requests-2.25.1 urllib3-1.26.5
(venv) $ exec bash -l
$ cd ~/bin
$ ln -sf venv/bin/grip grip

これで、~/binにPATHが通っていればメイン環境への影響なくgripコマンドが 使えるようになりました。

$ pip list --user

ユーザー環境へのpipによるパッケージ導入なく、悪影響の心配が無い形でgripが 導入できていることが確認できました。

Python: pipx (automatic)

前記の様な手動での仮想環境を使った導入をするのは、何がどうなっているのかを学には いいのですが、少々面倒です。

単にDebianのOS環境をクリーンで安定に保ったまま、最新モジュールをDebian外のレポから 持ってきてインストールし使用したい時には、pipxを 使うと透過的に自動化できるので便利です。

PyPIで見つかるリーモートからのインストールはパッケージ名だけの以下でOKです。

$ pipx install grip

テストビルドしたローカルのwheelの場合には、必ず./を前につけたファイルパス名の以下でOKです。

$ pipx install ./test-code.wheel

pipxは、Debian Bullseye/testingからは、 2021/6/18の現在落ちていますが、Bullseye環境で使えるパッケージが 最近アップロードされています。 https://packages.debian.org/sid/pipx