YAMAGUCHI::weblog

海水パンツとゴーグルで、巨万の富を築きました。カリブの怪物、フリーアルバイター瞳です。

wheelのありがたさとAnacondaへの要望

Python

はじめに

こんにちは、Python界のラファエル・ナダルです。全豪オープンテニス、盛り上がりましたね。さて、先日次のようなエントリーを立て続けに書いたんですが、「なぜAnacondaに関しての記述がないのか」という突っ込みをもらったので、参照用にメモを残しておきます。

なおこの記事の作成にあたっては @aodag に数多くのアドバイスをいただきました。この場を借りて感謝。

TL;DR

condaの開発者はPyPAともっとコミュニケーションとってほしい。

前提

この記事はPythonを触り始めたばかりだけど、パッケージ管理ツール等々のスタンダードがどのようになっているかなど、経緯がわからず混乱した人向けに現状を把握するための補助として書いています。読み物として読んでもらえれば幸いです。

予備知識1:Pythonでの標準策定プロセス

PythonにはPEP(Python Enhancement Proposal)というものがあり、Pythonの言語仕様そのもの、実装の変更、3rd partyなどで提案されてから広く受け入れられた機能などを標準に取り込むための提案はこのPEPの形式で提出され、PEP Editorsに承認されたものが標準に取り込まれます。

つまりPEPで明文化された仕様が決定されれば、提案元の3rd partyパッケージの実装依存にならず、その仕様を汲みさらに便利な機能を追加した新たな3rd partyを安心して見守れる、というわけです。このサイクルによってPythonの標準機能は発展しています。

予備知識2:パッケージングツールとパッケージインストーラ

  • パッケージングツール : PyPIなどで配布するモジュールをパッケージするためのツール。パッケージ作者以外は特に意識することはありません。
    • eg) setuptools, wheel
  • パッケージインストーラ : PyPIなどで配布されているモジュールをインストールするためのツール。通常はこちらを使うことばかり。裏側で何をしているか意識することは少ないです。
    • eg) easy_install, pip

現在は setuptools, wheel, pip は virutualenv とともにPyPA (Python Packaging Authority)で管理されています。

予備知識3:Python Language Moratorium

PEP-3003で決められた言語仕様やビルトインを一定期間フリーズする宣言。Python2系からPython3系に移行するにあたり、言語仕様を一旦フリーズして、Python3.1からはPython2.6へ、Python3.2からはPython2.7へそれぞれ言語仕様をバックポートし、メジャーバージョン移行のための猶予期間をもたせるためのもの。また同時に、Python3.3以降はまた新たに言語仕様の変更や新しいビルトイン等を導入可能とも定めています。

wheelのありがたさ

wheel以前

3rd partyライブラリである setuptools が利用していた egg と呼ばれる形式を使ってバイナリパッケージ（C/APIを利用したpure Pythonでないパッケージを事前ビルドしたもの）を配布していました。この egg 形式はPEPで策定されたものではなく、setuptools が独自に決めたものでした。標準パッケージである distutils や先の setuptools が setup.py sdist で生成する sdist はソースパッケージの配布形式であり、バイナリパッケージに関してはサポートしていません。（ところで実は現時点でも sdist の仕様が実は決まっていないというのは後で触れます）*1

一方で pip が標準になる以前、は、PyPIにあるパッケージのインストールは easy_install コマンドで行われていました。easy_install コマンドは setuptools もしくはそれをフォークした distribute （のちに setuptoolsにマージ）をインストールすると、そのエントリーポイントのコマンドとして利用できました。しかし後発の pip がパッケージを利用するだけの人からすると便利だったので、徐々に pip のシェアが伸び、パッケージインストールのためのデファクトスタンダードとなり、のちにPythonの標準配布に pip を同梱させる “ensure-pip” のためのPEPが策定されます。

ところがここで問題がありました。egg はすでにデファクトになっていたものの、作成した egg はメジャーバージョンの違いはおろか、マイナーバージョンが違っただけで動作しなかったため、パッケージ作成者は細かなバージョン単位での egg を作成する必要がありました。利用者も自分が利用しているPythonのマイナーバージョンにあった egg がないとインストールすることができませんでした。理由はわからないですが、おそらくこのような不都合から*2 pip は sdist 形式のパッケージを一度手元に落としてきた後、それをビルドして bdist_egg とした後にインストールするという処理を行っていました。せっかくの egg が台無しです。

wheel

そんな状況がある一方で、wheelの開発がされていました。wheelはパッケージングツールであり、それで生成されるパッケージはwhl形式となっています。wheelがなぜ開発されたのか、その理由は筆者が本家サイトに書いてくれているので読んでみると面白いです。

読めばわかりますがwheelはeggが抱えていた問題を解決するための仕様であるPEP-427やPEP-376を元に作られました。

No one has to rewrite setup.py for their own or the 20k+ other packages on PyPi unless a different build system does a better job.

Wheel が目指しているのは銀の弾丸ではなく、少しずつ既存の方法を解決していく地道な解決策であることが読み取れます。

何よりも大きいのはメジャーバージョンの違いも含めて、1つの whlでインストールされることです。そして、pipもバージョン7.0よりwhl形式に対応しています。このおかげで pip を利用したパッケージのインストールが高速になりましたし、Pythonのバージョン違いも神経質にならずに済みます。またバイナリインストールが可能なので、pipでsdistからビルドする際にあったような、依存ライブラリがない、という状況も改善されました。これはPEP-427やPEP-376だけでなく、複数のLinuxディストリビューションでも動作するようにPEP-513で規定したことによります。（manylinux1）

このような経緯でpipとwheelを支える多くの仕様が標準で決められ、必要なものもいま議論されています。一つ大きなピースがあるとすれば sdist の仕様が実はPEPで決まっていないというところです。これも現在PEP-516、PEP-517で議論中、PEP-518はすでに策定済みとなっています。これが決まって setuptools による実装依存の仕様がなくなり、もろもろのPEPを実装しているPyPA管理下の distlib が対応していけば、いよいよ setuptools から解放されます。すべてPEPで定義された仕様を元にパッケージングができるようになり、これでPyPIにあるものがすべてWheelになれば皆が知らないうちに幸せになるわけです。

このサイトにあるように、すでに主要なライブラリのWheel化はかなり進んでいます。データサイエンス系のライブラリ（numpy、scipy、scikit-learnなど）もWheel化しています。Pythonしか使わないのであれば、データサイエンティストの皆様もwheelのおかげで特にインストールされている共有ライブラリなどを気にせずにパッケージをpipでインストールできるようになっています。pip の後ろで多くの人たちが議論を重ね、今あるものを壊れないように作り替えてきました。（pip のダウンロードが wheel のおかげで高速化されることを実装される前から知ってた人がどれくらいいましたか？意識しないでも壊れることなく動いていたのは彼らの努力のおかげです）

Anaconda

condaパッケージ

しかしながら、データサイエンティストの方々はまずAnaconda（conda）をインストールするという流れが最近あります。まあPython以外にも、そもそもランタイムが異なるRを使ってみたり、Scalaを使ってみたりすることもある人なら納得はできます。

しかしMinicondaならどうか？これならPythonとcondaしか入れないのであれば別に virtualenv と pip とできることは変わらないのではないか、と思いますがここでややこしい事情が出てきます。先の sdist のフォーマットです。たとえばここにあるAnacondaのパッケージを見てましょう。

たとえばJupyterの場合のパッケージはこれです。（Pythonのバージョンに応じたtarballがある）

これを展開してみるとこうなります。

% tree jupyter-conda
jupyter-conda
├── info
│   ├── files
│   ├── index.json
│   ├── meta
│   └── requires
└── lib
    └── python3.5
        └── site-packages
            ├── __pycache__
            │   └── jupyter.cpython-35.pyc
            ├── jupyter-1.0.0-py3.5.egg-info
            └── jupyter.py

見たことない形をしています。これは setuptools で吐かれる sdist や、wheelとは異なる形式です。*3ではいったい conda の形式はなんなんでしょうか。Anacondaの公式ドキュメントにパッケージのビルドについて書いてあります。

conda はパッケージインストーラであると同時にパッケージングツールでもあり、 conda ではまったく独自のパッケージング方法とホスティング方法を使ってパッケージを配布、インストールしているのです。これは現状 wheel と互換性はありません。

conda パッケージはPyPIにアップロードされているパッケージを元に作成することも、スクラッチから作ることもできますが、いずれにせよこれはContinuum Analytics社の独自仕様です。

なぜこんなことになっているのか

これは conda の開発履歴とPEPの策定時期を見てみると理由が見えてきそうです。まず conda の開発履歴をたどってみると、GitのログやChangelogから、condaのバージョン1.0が 2012年9-10月ころにはあったと書いてあります。

% git log --reverse --pretty="%h %cd - %s" | head -5
c9aea053 Mon Oct 15 17:14:59 2012 -0500 - first commit
acd8144f Mon Oct 15 17:16:45 2012 -0500 - add conda files
e40c59cb Mon Oct 15 17:17:29 2012 -0500 - add git ignore
967bb3a8 Mon Oct 15 17:29:01 2012 -0500 - since the already released version of conda is 1.0, this should be 1.1
b1120484 Mon Oct 15 17:47:43 2012 -0500 - remove pyc files

開発はもう少し前からされていたことを考えても、開発に着手したのは2012年前半と見てよいでしょう。一方で、wheelを標準とするためのPEPであるPEP-427が作られたのが2012年9月です。実際にドラフトとして採用されるまでの期間を考えるとそれより前には書き始めていたわけです。実はこの頃、Pythonのパッケージ管理方法の議論が活発でした。その様子は Python-Dev のメーリングリストを見てみるとよくわかります。

この頃の話を詳細にすると、またこれはこれで非常に長くなるのでもろもろ割愛して要点だけ記すと

  • Python 2.7でPython2系の終了が決まっていて、Language Moratorium後の初のバージョンPython 3.3が出る時期だったので、パッケージングについての議論が活発になっていた。（Python 3.3.0のリリースは2012年9月）
  • setuptools と distribute の対立が大きくなり、 distribute がメインストリームになりつつあった。（2013年に distribute が setuptools にマージし、 setuptools はその後 pip や virtualenv も管理しているPyPAへ移管された。）

このような状況だったので conda の開発陣が業を煮やして自分たちでパッケージマネージャを作りたくなった気持ちもわからないではないです。実際、そのような気持ちだったであろうことは彼らの資料から見て取れます。*4

でもやっぱりcondaには歩み寄って欲しい

とはいえ、もう今は wheel がPEPで策定され標準パッケージング形式で決定していて、setuptools と pip でなんとなくでしか決まっていなかった sdist の仕様もきまりつつあり、すべて標準で決まってるんです。それだけじゃなくて、入れたパッケージをどう管理するか（誰がどういう理由でインストールしたかとか）とか、細かいパッケージの仕様まで長い年月をかけて標準で決めてきました。またパッケージの配布に関してもAPIがPEPで定義されています。これらは長い時間かけてPythonコミュニティが今動いているものをなるべく壊さないようにしつつ、コミュニティ全体がもっと便利にPythonを使えるように、と決めてられてきたものです。

このような状況を断片的にでもリアルタイムで見てきたので、いま conda がパッケージングに関してその流れを分断している状況は、個人的には悲しくもあり腹立たしくありという気持ちです。

conda が便利なのはわかりますが、勝手に独自パッケージを作って独自方式で配布するのではなく、パッケージを wheel 互換にしてくれて、PyPIにも whl 形式でパッケージをあげてもらえるような流れを作って欲しいと思います。実際に先にContinuum Analytics社のTravis氏のスライドで不満が漏らされていた numpy ですが、いまは whl 形式のパッケージが配布されているので、何の苦労もなく pip ですんなりインストールすることが出来ます。 conda の開発者が積極的にPEPの策定や wheel の作成と配布に関わってくれれば、コミュニティ全体でその恩恵にあずかれるので、そうなることを願うばかりです。*5

参考リンク

この記事にある細かな話は @aodag が過去のPyCon JPの発表で事細かに歴史的経緯含めて説明してくれているので、知りたい人はそちらもどうぞ。

PyPA（Python Packaging Authority）でパッケージング関連ツールの履歴を整理してくれています。

またPyPAで「現在推奨のパッケージツール」に関するドキュメントを常に更新し続けてくれています。迷ったらここを読みましょう。

最新のパッケージング動向を知りたいという人は各MLなどを追ってみましょう。

関連PEPとか

Appendix

  • Q1: buildoutについて触れられていませんが？
  • Q2: 開発環境の切り替えについて知りたいです。
  • Q3: 各OS（macOS、Windows、Linuxディストリビューション等）でのパッケージ管理ツール経由でしかパッケージを入れたくありません
    • A3: その場合新しいバージョンのパッケージは登録されるまで待つしかないですが、それも一つの方法だと思います。いずれにせよそれらもwheelベースになるものと思われます。

コメントに関して

wheelのありがたさとAnacondaへの要望 - YAMAGUCHI::weblog

要望があるならcondaの開発者に直接伝えるべき (=>https://github.com/conda/conda/issues)。こんなとこで日本語で書いても1ミリも伝わらない。コミュニケーションについて非難している本人が一番コミュニケーションをとっていない。

2017/02/02 18:54
b.hatena.ne.jp

conda のパッケージのビルドに関するissuesはそこじゃなくて conda-build のレポジトリだし、記事公開時にすでにこの記事で書いたようなissueは上がってます。コミュニケーション云々いうなら、コメント欄開けてるので、記事コメントに直接書いてください。

*1:buildoutなどのZope関連のツールの話もあるのですが、これ以上書いていくととてつもない分量になるのでこの記事では書きません。

*2:pipでeggのインストールがサポートされなかった理由をかなり調べてみたけれど、決定的な理由が見つからなかった。

*3:比較したい人はこちらでどうぞ https://gist.github.com/ymotongpoo/7068beddbc7cf8a2015338c64425ca06

*4:ちなみにスライドの作者のTravis E. Oliphant氏はSciPyの作者

*5:自分はデータサイエンス系のこと以外にもPythonを使うので、そのためだけにcondaを入れたくはない。

Pythonの仮想環境構築 2017.01版

Python

はじめに

こんにちは、Python界のテリー・ギリアムです。こんな記事を見かけて、Pythonの開発環境を作るのが面倒という認識が広まるのは良くないなあと思って書きました。ただの突っ込み記事です。

qiita.com

そのツールほんとに要りますか？

出だしにこんなセクションタイトルがありました。

その仮想環境本当に必要ですか？

たしかに仮想環境要らないひとは要らないよねっていうのは同意です。その場合、入ってるPythonのsite-packagesにどんどんパッケージがインストールされるだけなので、手動で消せる人はそれでいいし、そもそもパッケージのバージョンとか知るかって人はそのままパッケージインストールすればいいと思います。

とはいえ、複数のプロジェクトでパッケージのバージョンがぶつかったら困る人とかいるし、そういう人は仮想環境を使うことになるでしょう。で、件の記事ではいろいろなツールを紹介していますが、そもそもそんなにツール要りますか？というのが本記事の主旨です。

The Zen of Python

PythonにはThe Zen of Pythonという、Python自体の考え方や、それから派生したPythonで開発する上での指標となるものがあります。見たことがない人は次のコマンドで確認してください。

$ python3
Python 3.6.0 (v3.6.0:41df79263a11, Dec 23 2016, 08:06:12) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

今回の話につながるところでいくと、次の3つがあります。

  • Simple is better than complex. （シンプルなのは複雑であることよりも良い）
  • There should be one– and preferably only one –obvious way to do it.（1つだけ、できれば唯一、の明らかな方法があれば良い）
  • If the implementation is hard to explain, it’s a bad idea.（その実装の説明が難しいなら、そのアイデアは良くない）

ツールに関してもそうです。シンプルなものがあればそれを使おう、なるべくシンプルな構成にしよう、という考え方です。

virtualenv (venv)があればたいていのことは済む

pyenvを便利に使ってる人はいるんでしょう。しかし、pyenvのpython-buildは便利かもしれませんが、そんなに細かくPythonをインストールする必要がある人ってどれだけいるんでしたっけ？

pyenvはPythonのインストールから含めてオールインワンの実行環境を提供したいという目的があるのでしょうが、そもそもPythonのマイナーバージョンのアップデートはそこまで大きくなく、マイナーバージョンのリリースもかなり慎重です。実際マイナーバージョンでの下位互換性は高く、マイナーバージョンのアップデートも1年に1回程度です。公式のリリース情報のページで確認できます。

プロジェクトで稼働させているバージョンを固定させているならそのバージョンだけ入れればよいわけですし、マイナーバージョンごとにアップデートを行うにしても1年に1度あるかないか、さらに攻めた環境でマイクロバージョンごとにインストールするにしてもたかが知れています。（マイナーバージョンは大概がセキュリティフィックスか明らかなバグ修正。）であれば、pyenvでPythonを新規にインストールする必要ってどれくらいあるんでしょう。マイクロバージョンごとに確認しなければいけないライブラリ作者ぐらいでしょうけれど。

Pythonのインストール自体は configure、make、make installをするだけなので、かなり簡単にビルドできます。（pyenvでインストールを実行している内容もこれです。先ほどのThe Zen of Pythonでいえば “Explicit is better than implicit.” の項に当てはまる内容ではないでしょうか。）

で、本題の「どのツールが必要なの」という点ですが、基本的に virtualenv (venv) があれば事足ります。

venvのみを使う場合

venvはそもそもvirtualenvというツールがPython2系で広く使われてデファクトスタンダードになった時期がPythonのLanguage Moratoriumの期間に重なり、その時期にPython3ではこれを標準に入れようという動きから取り込まれたものです。

ですので、基本的には同じものと考えてもらって問題ありません。またパッケージ管理ツールに関しても現状ではpipに落ち着き、後ろで使われるパッケージングもwheelで安定したので、この辺はpipがデフォルトでインストールされる最近のPythonでは特に気にする必要はありません。

もしこの辺のいきさつを知りたい場合は次のエントリを参照してください。（古い話なので、そこまで知りたい人でなければ特に気にしなくてよいです。）

ただし、venvはPython3以降でしか使えません。Python3以降のみで使う場合には venv で事足りる、という認識でよいと思います。たまに例外もありますが、その場合は virtualenv を使えばよいでしょう。（Debian系では venv に必要な ensure-pip が設定されてないバイナリがインストールされることがあるのでその場合は python3-pip を入れてpipで virtualenv だけ入れればよいです。）

venv が入っていれば次のコマンドで仮想環境を作成できます。

$ python3 -m venv hoge
$ . hoge/bin/activate

virtualenvを使う場合

Python2系とPython3系両方でうまくやりたい場合は virtualenv を使えば良いです。基本的に venv は virtualenv の中からPython3系だけでうまくやるために必要なものだけ切り出してるので、基本的にできることは変わりませんし、メジャーバージョンを切り替えるような場合は virtualenv 一択となります。

virtualenvはPython本体のバージョン切替には使えませんし

先のエントリではPython本体のバージョン切り替えができないと書かれていますが、ふつうにPythonのバージョンの切り替えもできますよ。virtualenv のオプションを確認してみましょう。

  -p PYTHON_EXE, --python=PYTHON_EXE
                        The Python interpreter to use, e.g.,
                        --python=python2.5 will use the python2.5 interpreter
                        to create the new environment.  The default is the
                        python2 interpreter on your path (e.g.
                        /usr/bin/python2)

たとえば、Python2系がデフォルトの環境で、virtualenvでPython3系の環境を使いたいとき。

% python -V
Python 2.7.9
% python3 -V
Python 3.4.3
% virtualenv --version
1.11.6
% virtualenv -p python3.4 hoge
Running virtualenv with interpreter /usr/bin/python3.4
Using base prefix '/usr'
New python executable in hoge/bin/python3.4
Not overwriting existing python script hoge/bin/python (you must use hoge/bin/python3.4)
Installing setuptools, pip...done.
% which python
/home/ymotongpoo/hoge/bin/python
% python -V
Python 3.4.3
% deactivate
% python -V
Python 2.7.9

ちゃんとPython2系がデフォルトの環境でPython3.4の環境を作れていますね。

virtualenvwrapperについて

virtualenvwrapper は virtualenv での環境作成や環境の切り替えを便利にするためのラッパーツールなので、内側で何をやってるかわかれば、使う使わないは本人次第です。 virtualenvwrapper でやっていることは次の内容だけです。

  • mkvirtualenv では特定のディレクトリ以下（eg. $HOME/.virtualenvs）で virtualenv のオプションをそのまま受け取って環境を作成する
  • workon では deactivate を実行し、指定した環境の bin/activate を実行する
  • rmvirtualenv では、mkvirtualenvで作成した仮想環境のディレクトリを削除する。

「ディレクトリの移動などが本当に面倒」という人であれば使えばよいと思います。

まとめ

巷にいろいろとツールがあり、それらを紹介するエントリーがたくさん見つかるので、何か複雑なように見えますが、その実はシンプルです。デファクトスタンダードを使って、それをみんなでよくしていこう、というPythonのエコシステムに乗っかるほうがいろいろと便利ですよ。

2017.01.30 追記

ブコメやTwitterでの反応を元にコメント。

Pythonの環境設定でむかついてる人はとりあえずこれをコピペで実行してください 2017.01

Python

はじめに

こんにちは、最近Pythonをまた書き始めたマンです。なんか古い記事が参照されててだいぶ害があるので現状にあったやつにします。

要点

これからPythonを使い始める人、という前提に立っているので今更Python2系を使い始める意味はない。*1ということでPython3系（現時点最新安定版のPython3.6.0）を使いましょう。

  1. 標準を使うのがよい（venv + pip）
  2. 自分がよく分かってないツールは使わないほうがいい

Python2系を使う人は、上にリンクしてある記事にあるとおりなんですが、Python2.7を使うのであれば pip + virtualenv 一択だと思います。やり方は下にある内容と変わりません。

以下コピペ

macOS

Homebrew使ってるんなら3.6.0を簡単に入れられるのでそれで。

% brew install python3
% python3 -m venv hoge
% . hoge/bin/activate

あとはpip（pip3）で好きなもの入れればいいと思います。

Linux

ディストリビューションによってパッケージ管理ツールでインストールできるPythonのバージョンが違うけど、3.5は入ってると思うのでmacOSと同じ。*2

% sudo apt-get install python3
% python3 -m venv hoge
% . hoge/bin/activate

(2016.01.27 15:46 追記) Ubuntu/Debian系のvenvだとpkgresources-0.0.0とかいう謎パッケージがぶっこまれて、pip freezeでrequirements.txtを作ると他の環境で復元できないのでデンジャー。virtualenv入れてそっち使ったほうが良さげ。(by @aodag)

% pip3 install virtualenv
% virtualenv hoge
% . hoge/bin/activate

Windows

インストーラー使うかchocolatey使うかすればよいのではないかと。chocolateyなら簡単にPython3入る。

> choco install python3
> python3 -m venv hoge
> .\hoge\Scripts\Activate.ps1

まとめ

virtualenv (venv) もpipも標準で入ってるしそれ使えばいい。

追伸

別にHomebrewやMacPortsやchocolatey使うの嫌だったらインストーラーが公式サイトにあるからそれで入れればいいと思いますよ。

www.python.org

*1:Ansibleとかでやむを得ない人はいるかもしれない

*2:Ubuntu 16.04 LTSだといまは3.5.1が入るらしい。

Windows 10の開発環境を整えた

Windows PowerShell

はじめに

こんにちは、大正デモクラシーです。年末年始に実家に帰るにあたって、Windows 10がインストールされているXPS 13を持って行ったんですが、実家で庭木の剪定以外にやることがなかったので、それ以外の時間はずっとコード書いてました。しかし、持って行ったマシンの開発環境がまったく整ってなかったのでいろいろ設定しなおしてとりあえずいい感じになったので、その作業メモを書いておきます。

TL;DR

これまでLinuxやmacOSで育ててきた環境をWindows 10で使うことはあきらめて、これらのツールをとりあえず入れました。

MSYS2を入れて捨てた

はじめはMSYS2を使ってLinuxやMacと似たような環境にしようかなと思ってごちゃごちゃやってたんですが、中に入ってるパッケージが古かったり、いろんなものとの相性が悪かったので捨てました。入れて作業して捨てるまでに1日半くらい使った気がします。まあMSYS2のいろいろな設定を見て回って一通り触ってみて良し悪しがわかったので、それは良かったとしましょう。

PowerShell on cmderで生きていくことにした

@ryushi と @aodag にどうしよっかねえ、と相談した結果、WindowsはWindowsの世界で生きたほうが楽になれそうだったので、全部すっぱり捨ててPowerShellに移行することにしました。bash on Windowsなどを使う、という方法もあるかもしれませんが、どうもしっくりこないなと思ったのでやめました。今度暇なときに触ってみようと思う。

さて、Windowsを使っていくとはいえ、素のPowerShellはフォント回りをいじるのにレジストリいじったりしないといけない感じだったので、10年前とかに無駄にRegseekerで遊びまくって何度もWindows XPを再起不能にしていた身としては、極力レジストリはいじりたくない気持ちがあったので、ターミナルエミュレータのcmderを使っていくことにしました。

cmderを入れた理由はこんな感じです。

  • デフォルトでもろもろのコンソールを立ち上げられる
  • タブで各コンソールを管理できる
  • フォント回りを柔軟に設定できる
  • デフォルトで設定されている profile.ps1 がいい感じにGit for Windowsと連携してくれる
  • 上記の profile.ps1 が追加でカスタムの profile.ps1 を読み込む口を用意してくれている

Git Credential Manager for Windows

PowerShellで生きていく設定はできたので、次はコードを持ってくるために必要なGitの設定。ここで問題になるのは、自分はGitHubで2FAを使ってるので、そこをどうするか。LinuxやmacOSではいい具合にcredential managerを使えるので、HTTPSであってもパスワード入力なしにpushもできるんですが、Windowsではデフォルトではそれをサポートしていません。で、いい方法ないかなと思って探したらやはりありました。

インストーラーがあって、Gitのインストールも一緒にしてくれる。これを入れたら2FAにしたGitHubアカウントでも快適にコードの管理ができるようになりました。

nvm for Windows

正月休みにVisual Studio Codeの拡張を更新するかと思っていたので、node.jsの環境をまず整えることにした。nvmを使って入れたいと思っていたら、ちゃんとWindowsに対応したものがあったのでこれを使ってインストール。

chocolatey

Windowsの環境をまじめに設定するのがWindows XP以来なので変化に驚いています。Visual Studio向けにはNuGetがあってなんかいい感じらしい、ということは聞いていたのですが、それ以外の普通のツール（パッケージ）管理用にchocolateyというツールがあるのをいまさらながら知りました。これでいちいち自分でパッケージを探してきて入れなくても済むんですね。本当に便利。

posh-git

PowerShell上でGitを扱うためにposh-gitをインストールしました。これはchocolateyにパッケージとして登録されているのでそちら経由でインストールしました。

> choco install poshgit

Python 3.6

Pythonをちょろっと書く必要があったのでPythonもchocolatey経由でインストール。

> choco install python3

Go 1.7.3

当然Goもインストールした。最新版がパッケージ登録されている。

> choco install golang

細かなこと

権限回り

Windowsは権限回りがかなり厳しく、PowerShellでいろいろなことを行うにはもろもろの設定が必要でした。ただしこれらもコマンド1つで設定を変えられるのでかなり楽な印象。

> Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

（追記: 2017/01/05 18:13:00）

Windows 10の開発環境を整えた - YAMAGUCHI::weblog

powershellはset-exectionpolicyでガバガバにするの止めて、powershell.exeの起動時のオプションに「-exectionpolicy remotesigned」付けて権限をプロセス単位に閉じ込める方が良いと思う。

2017/01/05 17:30
b.hatena.ne.jp

なるほどそういう方法があったのですね！早速cmderのPowerShellの起動オプションに追加します！

コマンドレット

PowerShellのコマンドレットを覚えるのは大変 *1 だけれども、Get-Help コマンドレットで対象のコマンドのオプションはすぐにわかるし *2 、オプションで -Online をつければ、ブラウザで詳細なドキュメントがすぐに読めるのでとても良い。

*1:Unixシェル的なエイリアスが用意されているけれど、なるべくWindowsの世界で生きてみるために使わないことにしている

*2: ところで Get-Help のエイリアスは man になっているあたりが優しい

YAMAGUCHI::weblogの2016年を振り返る

misc

はじめに

こんにちは、Go界の低温調理器です。今日でまた1歳年齢を重ねました。例のやつです。

関連エントリ

なんだかんだで振り返りを10年やってるっぽい。

ymotongpooの2016年

昨年立てた目標

昨年立てた目標的なものを見てみます。この項目毎年年末に適当に書いてて、まったく翌年覚えてないことに気が付きました。

  • 動画関連技術で遊ぶ
  • アクションカムと360度カメラで遊ぶ
  • Androidで遊ぶ
  • 資産運用を真面目に考える

動画関連技術で遊ぶ

家の録画機で遊んでいたくらいで、仕事では積極的には動画で遊んでいませんでした。YouTubeにいたときと比べると動画に触れる機会がかなりすくない。Android関連でいうとExoPlayer2が地道に対応コーデック増やしているのを追いかけていたりするくらいなので、来年はその辺で仕事もっと作れないかなあと考えています。

アクションカムと360度カメラで遊ぶ

昨年の今頃は360度動画をカメラとかが来るかもと思っていろいろ調べていた記憶がよみがえってきました。個人的には旅行に行ったりするときはアクションカムや360度カメラを持って遊んでいるのですが、やはり加工に手間がかかる部分をどう解消するかというのが課題ですね。

Androidで遊ぶ

Androidアプリは下位互換を捨てると年々書きやすくなっている印象で、Android Studioの進化でより開発がしやすくなってきたなあと感じました。もちろん、業務で扱ってるから下手にはまることはないんだけれど、客観的に見てかなり直線的に開発できるようになったと思います。

資産運用をまじめに考える

まじめに考えた結果いろいろ動き始めました。また pyspa Slack の #kane チャンネルでいろいろと話してると資産運用やら税制の話などがあって面白いです。

今年特にやってたこと

まずそもそも「お前の仕事はなんなんだ」っていうところから始まるんですが、自分の職種は、自社で開発した製品やサービスを広く紹介すると同時に、フィードバックを集めて製品チームとともに問題を解決していく、というのが主な役割です。これに関連すればなんでもする、という役職なので、コミュニティの場でプレゼンをすることもあれば、サンプルコードを書くこともありますし、PRDのレビューをすることもあれば、PRDを書くこともあります。

仕事など

今年はAccelerated Mobile Pages（AMP）のGoogle検索対応が年初からあり、それも何段階かのリリースがあったため、この1年はだいぶAMP関連の仕事が多かったです。

いくつかご一緒させていただいた企業のブログエントリにもリンクを貼りましたが、ほかにもすでにリリース済みのものや現在進行形のもの合わせて多くの企業にご協力いただいています。AMPはGoogleがイニシアチブを取っているオープンソースプロダクトではあるけれども、実際にAMPページを生成してくれるサイトオーナーがいてこそのものなので、実際に取り組んでくださった企業にはご迷惑をおかけしたこともありつつ、AMPを良いものにするために多くのフィードバックをいただき、それらの多くがすでにレポジトリに反映されています。

またProgressive Web Apps（PWA）を全面に押し出したのもこの1年でした。AMPで素早くファーストビューをとり、PWAでは総合的なウェブ体験の向上を、という提案は個人的にはかなりおすすめではあったのですが、まだまだ様々な課題や懸念もあり、まだまだ実際の導入事例は少ないのが現状です。来年一年はもっと増えることに期待しつつ、コツコツと取り組みを進めていくしかないですね。

Chrome Custom Tabs や Smart Lock for Passwords はひきつづき一押し機能なので来年もプッシュしていきます。

変わり種としてはTangoの担当を始めたことが挙げられます。Tangoは個人的にはいま一番実用性が高い端末ではないかと思っていて、特にB2CではなくB2Bにおいて受ける端末だと思っています。Unityのプラグインもなかなかに使いやすくなっていると思うので、来年はもっと多くの事例の支援ができればなあとぼんやり考えています。

Anova

今年、と言っても1か月程度だけれど、Anovaの低温調理器が本当にすごいです。昨日のエントリにも書きましたが、いままでなんとなくでやっていた肉料理に対する見方が完全に覆されました。ステーキやローストビーフなど、塊肉に対して中心までどのように火を通すか、これは料理において大きな課題でしたが、完全に再現可能な形で容易に実施できるのは科学の勝利と言っていいと思います。

鶏むね肉のサラダチキン、ローストビーフなどはすでに何度か調理して完全にその質に満足しているので、来年はAnovaを活かしてより高度な低温調理の世界を堪能したいと思います。

海外出張

2016年は例年に比べて多くの出張がありました。面白いのはそれぞれの出張が全部違うプロジェクトだったことで、来年もおそらく同様のスケジュールになりそうです。

多くのプロダクトを抱えるのは日々の仕事においては大変なことも多いですが、多くの人と知り合えるという利点もあるので、これからも各地にいる製品チームに多くのフィードバックしていきます。

スペイン語

海外出張の合間に9月にスペインに行ってきました。

ymotongpoo.hatenablog.com

スペインは期待していた以上に素晴らしく、これなら毎年来たいと思うくらいでした。そこで現地の人との交流のために旅先で始めたスペイン語の勉強ですが、無理のないペースでちょこちょことやっていました。最近はさぼりがちになってしまったけれど、スペイン語は面白いので、長期的に勉強したいなあと思います。

ジム

今年の後半はずっとジムに行っていました。半年でだいぶ体が変わってきたので、引き続きこの調子でやっていって、来年はさらなるレベルアップをしたいと思います。懸垂20回をコンスタントに達成できるようにしなければ。

来年に向けて

毎年これ書いてるけど、毎年忘れてるんだよなあ。まあでも書かないよりはマシと言ことで今年も書きます。

  • スペイン語の勉強
    • Duolingoだけでは限界があるので、まずは文法書的なものがほしい。
  • Pythonやり直す
    • numpyやらscipyやらをいじり始めたので
  • 資産運用を引き続き
    • お金は大事
  • ジム
    • コツコツ頑張ります