こんにちは、Pythonエンジニア育成推進協会 顧問理事の寺田です。私は試験の問題策定とコミュニティ連携を行う立場です。

みなさん、開発環境の構築はどうされていますか？特に初心者の方からするとどんな開発環境が良いかわからない部分は多いと思います。

2022年に開催されたPyCon KYUSHU 2022 KUMAMOTOで登壇した際に開発環境について6項目に分けて何をどういった指針で選んで利用しているかという点についてお話したのですが、それをまとめた内容を昨年の3月に、マイナビニュースさんのTech＋でコラムとして公開しました。

Pythonのおすすめ開発環境2022版

この記事から1年が過ぎ、2023年になった今の開発環境がどれくらい変わったのかについてお話をしたいと思います。

■私の開発環境変遷、Pythonやるならこれで問題なし

先に結論を上げしまうと、昨年からはほぼ変わっていないというのが回答になります。

こちらの表が以前書いた記事でご紹介した内容に2023年を追加したものです。

変わった点と言えば、その時々の要件に応じてバージョンを3.9か3.10を使い分けているという点くらいです。Pythonの標準実装であるCPythonは今でもおすすめのままかわりませんし、それ以外の部分に関してもこのままでも問題ありません。

今回は上記の6項目の中から特にフォローが必要な内容を取り上げたいと思います。

■Python3、どのバージョンを使うのがベスト？

現在、Pythonは12カ月ごとに新しいバージョンがリリースされており、昨年の10月に3.11がリリースされています。

このリリースでは新たな機能の追加やスピードアップが図られていますが、下位互換性が保持されていますので、内部的なAPIが大幅に変更されていない限りは基本的にどのバージョンを利用したとしても、書いたコードが動かないという事はめったになく、3.9で書いたコードは3.11でも基本的に動きます。

もし、新しい機能が入ったとしても予約語が増えている程度で、過去のプログラムで使用している関数とその予約語がバッティングしていないのであれば基本的に問題なく動きますし、動かなかったとしても少しのお直しで済むレベルです。

こうした背景がある中で、どのバージョンを使えばいいかといえば、追加された機能を使いたいという目的がなければ特に焦る必要はなく、もしメリットを感じたなら積極的に上げていくという方針で問題はありません。

バージョン選定において考える必要があるとすれば、利用したいライブラリの対応状況と、環境面の対応状況です。

例えばサーバーレスにするためにAWS Lambdaなどのサービスを利用する際、LambdaはPythonのどのバージョンに対応しているかを事前に確認する必要があるというようなことです。

私自身はWeb開発やデータ分析を中心に行っていますが、それをするにあたって環境やライブラリの対応状況が結構な影響を受けますので、対応状況を見極めてからどのバージョンを使うかを決めています。

動かす環境はまちまちですが、そこまで新しい環境ではなく、また、ライブラリのバージョンに依存しない形で構成していることから3.9の方が多少いいという状況のものが多いため、よく利用するのは3.9でその次が3.10になります。

3.11に関してはそろそろ使い始めてもいいかなと感じている段階ではありますが、3.11のメリットである実行速度が改善されたという点を生かせるほど速度に依存しているシステムが多くないため、飛びついてまでやるというものでもないと考えています。

とはいえ、今後のライブラリの対応状況や、動かす環境によっては今後、3.11を利用する場面が増えてくると思います。

ところで、3.10には構造的パターンマッチ（match-case）が追加されており、これを使った方がスマートに動かせる場合がありますが、私は3.9で動かすことを考えて今のところはあえて利用していません。

■インストール方法

PSFが公式に準備しているものを使っている人が多く、情報も多いことから私もこちらを利用しています。

後ほど紹介しますが、最近はDocker技術を使うことが非常に増えていることもあって、インストールはDockerが公式に出しているものを使って環境を構築することが増えています。

実際に動かすときの環境構築にもDocker技術を使うものが増えており、特にWeb系ではこの環境構築方法がより多くなっているため、適切なDockerのイメージを使うようにしています。

ちなみに、昨年の記事にも書きましたが、公式インストーラを使えば、3.9と3.10、3.11を一つのPC上に共存させることが可能です。ただし、同一マイナーバージョン内でのマイクロバージョンの共存はできません。

例）バージョン3.9.8：3＝メジャー、9＝マイナー、8＝マイクロ 　　→3.9.xと3.8.xは共存できるが、3.9.8と3.9.7は共存できない

■仮想環境

Python標準であるvenvモジュールが浸透していることもあって、利用している方が多いと思いますし、私自身もこちらを利用しています。

先ほどのインストールにかぶる話ではありますが、Dockerを使うことが増えたことで、venvで切らずともDocker内で完結するため、一つのOSに複数のPythonを入れるより、Dockerという仮想環境内で環境の切り分けをする機会も増えています。

また、従来であればPythonの仮想環境は一つのPCの中に複数のサードパーティ製パッケージを入れていましたが、近年は開発や本番の運用にDockerを使って仮想化していることが増えているため、あえてvenvを利用する必要がなく、私自身もDockerを使うケースではvenvモジュールを私は利用しません。ただし、ローカルで行う場合はvenvを利用しています。

■Pythonでのインストーラはpip

サードパーティ製パッケージをインストールする際にはpipコマンドを使っています。

詳しくは2022年版を確認して欲しいのですが、この時にお話したWheelというビルド済みの配布用バイナリパッケージがより便利になりましたので、いまもpipでインストールして利用しています。

■エディタはVSCode

コミュニティでもどのエディタが良いかという議論はいろいろな意見がありますが、私個人としてはPyCharm有料版も持ったままですが使う機会が減り、VSCodeを使う機会が多くなっています。

PyCharm自体は進化していますので独自の良さはもちろんありますので、利用している人も多くいますし、便利なことは確かです。

ただ、私はWebシステムを構築する時にはPythonやTypeScriptの2つの言語を主に使っているため、VSCodeの方が使い勝手がいいと感じています。

また、機械学習やディープラーニングをする場合にはGoogle ColaboratoryやJupyter Labを使っていますが、Jupyter Labの場合はVSCodeから使うこともあります。

VSCodeは無料で利用できる上、Web開発で使える優秀なプラグインが多いことから、Python関係なく、Web開発者でも利用する人が増えています。共同で何かを開発する場合には環境を合わせるのが楽なため、VSCodeが利用されるシーンが増えています。

■Dockerを使うこと

この1年で私の環境で大きく変わったのはVSCode＋Dev Container を積極的に使うようになったことです。

Dev Container を使う人の多くはVSCode経由で使っていると思います。

Dockerが動く環境がPCに必要などの条件はありますが、基本的にVSCodeの操作画面の中でDev Container が自動的に立ち上がってくれます。ここで、どういう環境を作りたいかなどの選択肢がでてきますが、チェックしていくだけで自分の環境をあたかもローカルにあるような状態で新しいDev Container を立ち上げてくれます。

エディタで書いたファイルと実行環境をVSCodeから見るとあたかもローカルにあるようにDev Container の中を操作できます。ターミナルで直接入ってテストすることもできますし、エディタでローカル上に直接書いたものでもシンクされてDockerに適切な形で配置され、すぐに実行できる状況が簡単に作り出せます。

この利点は複数台の環境があるときに、Dev Container の設定を共有しておけば、別のPCで環境が変わっても実行できる環境が手に入ることです。

私は普段、開発にLinuxやMacを利用していますが、GitでDev Containerの設定ファイルである .devcontainerフォルダを管理しておけば、どちらの環境でも同じ環境が整いやすくなります。これは複数人で開発するときでもほぼ同じ環境で作ることができるため、構築する面倒さから解放されます。

設定のコツをつかむまでは大変で、複雑な設定をするにはノウハウが必要ですが、一度適切に動くものができれば、開発者が途中で増えてもGitから必要なものをダウンロードでき、手順を共有すればすぐに開発に参加してもらえます。

最近は本番環境をDockerでホストすることが増えていますが、そこで使うイメージ（例：Debianを使うなど）を決めている場合、MacやWindowsで開発すると起きたり、起きなかったりという問題が、Dockerで行うことで、本番で動くのと非常に近い開発環境を手に入れることが可能になりますので大きなメリットになると考えています。

では、バージョンをどうするかですが、多くの場合はMicrosoftが提供しているDev Container 用のPythonバージョンを使います。自動的にマイクロバージョンが変わってしまうのですが、私はバージョンに違いがあっても動くように開発しているため、Microsoftが提供するものをそのまま利用しても特に困ったことはありません。

プロダクション環境はそうはいきませんので、公式が出しているDockerイメージを使うことが多くなります。

また、CI/CD（Continuous Integration：継続的インテグレーション／Continuous Delivery：継続的デリバリー）に基づいた環境を構築するとなれば、ある意味でDocker技術が新しい環境構築に求められる技術になるだろうと感じています。

Dev Container は今も機能が追加されており、非常に使いやすくなっています。情報が新旧入り乱れているため、情報を非常に追いかけにくい状況ともいえますが、いち早く覚えられればDockerへの抵抗感がなくなり、開発環境の共通化・安定化がさせやすいというメリットがあると思います。

ちなみにDev Container で昨年困ったことは、マイクロバージョンも併せてテストしたいと考えたときでした。

秋ごろに仕様が変わったことで、今は標準のコンテナイメージを3.10.6に固定して、Dev Container 用に設定できるようになり、徐々により便利に仕上がってきていると感じています。

■さいごに

今回お話した内容は、知らなかった人にとっては新しいことが多く、面倒に思うかもしれませんが、覚えれば開発環境への理解が深まります。

この先にある未来として、取り組んでいる企業が増えているGitHub Codespacesという、クラウド上に開発環境を作ることができ、ブラウザ上ですべての開発を完結できるという仕組みがあります。これを支える技術として、VSCodeやコンテナ技術があり、特にDev Container は密接な関係があります。

開発環境をクラウドで動かすにはDev Container のように適切な設定ができていれば、どこでも動く環境が手に入るはずです。

VSCodeの自体はWeb技術で出来ており、ブラウザ上でVSCodeが動くのは普通にある話です。VSCodeをブラウザ上で動かして、接続先がクラウド環境という組み合わせが出来ます。

先ほど言ったWebコンテナを駆使、理解することでクラウド環境の開発、すなわち、ローカルにデータを持たずにできるということが実現しつつあります。

極論を言えば、開発環境をローカルに作らないという事が可能になりつつあると言えます。

こう言った取り組みはPyCharmの提供元であるジェットブレインズ社も取り組んでおり、PyCharmを中心にして、GitHib Codespacesのようなものをリリースしています。

私自身はいずれも使っていないため、細かい話はできませんが、こういったいろんな技術の組み合わせが盛んに行われ、流行りだしているという状況です。

私自身、昨年の夏ころからDev Container を積極的に使うようにしており、うまく利用できるようになった今は、プロジェクトを作ったら最初にDev Container を作り、必要なセットアップをしているという感じになっています。

というわけで、開発環境は基本的に変わりませんが、クラウド技術やDocker技術がより洗練されたことで、使いやすくなったことで、今までであれば一部の人が使うものであったDocker技術が、開発の世界に入り込んでいます。

開発環境の共通化は10年ほど前であればVMWareやVirtualBoxなどで共通化したイメージで開発環境を整えていましたが、それ自体のイメージが大きくなりがちで、共通化して配布するのは困難でした。それと比べるとコンテナ技術はより使いやすく、展開しやすいと思います。

すぐにやる必要はありませんが、便利で楽になる部分がありますので、ぜひDev Container を使って挑戦してみてください。