methaneのブログ

このブログに乗せているサンプルコードはすべてNYSLです。

hub コマンドの BDD がユーザードキュメントとして素晴らしい

OSSメンテナをしていると他人のPRやブランチをチェックアウトして何かを確認したいということは頻繁にあって、いちいち git remote add して fetch してってのが面倒なので Github 製の Github CLI クライアントである hub を愛用している。

でも hub コマンドって、ドキュメントがあまりなくて、 help コマンドの出力も最小限で、頻繁に使う一部の機能以外はほとんど使いこなせずにいた。

しかし、 hub コマンドが Cucumber を使って BDD をしているのを最近知った。「どういう仕組でBDDが動いているのか」は全くわからないけれども、 「hub がどういうコマンドを実行するとどういう動作をするのか」は凄くわかりやすい。

たとえば、 hub pr checkout コマンドの Behavior を見てみると、

Feature: hub pr checkout <PULLREQ-NUMBER>
  Background:
    Given I am in "git://github.com/mojombo/jekyll.git" git repo
    And I am "mojombo" on github.com with OAuth token "OTOKEN"


  Scenario: Checkout a pull request
    Given the GitHub API server:
      """
      get('/repos/mojombo/jekyll/pulls/77') {
        json :number => 77, :head => {
          :ref => "fixes",
          :repo => {
            :owner => { :login => "mislav" },
            :name => "jekyll",
            :private => false
          }
        }, :base => {
          :repo => {
            :name => 'jekyll',
            :html_url => 'https://github.com/mojombo/jekyll',
            :owner => { :login => "mojombo" },
          }
        },
        :maintainer_can_modify => false,
        :html_url => 'https://github.com/mojombo/jekyll/pull/77'
      }
      """
    When I run `hub pr checkout 77`
    Then "git fetch origin refs/pull/77/head:fixes" should be run
    And "git checkout fixes" should be run
    And "fixes" should merge "refs/pull/77/head" from remote "origin"
  1. mojombo/jekyll をチェックアウトしたリポジトリにいるときに
  2. hub pr checkout 77 を実行すると、
  3. hubが git fetch origin refs/pull/77/head:fixes を実行して、 (ここで "fixes" は上の Github API のレスポンスで判断していることがなんとなくわかる)
  4. git checkout fixes を実行してくれる

事がわかる。

例となるシナリオを用意して、どんな git コマンドを実行してくれるのかわかる。しらない git コマンドがあればそれは git のマニュアルで調べればいい。

コマンドごとにいくつかシナリオが用意されているので、 hub help コマンド名 するよりも、この feature ファイルを探して斜め読みするほうがずっと hub コマンドで何ができるのか具体的に理解できる。

Python 目線からの GAE/node.js Standard Environment 発表の解説

Google I/O 2018 で GAE/node.js Standard Environment が発表されました。

www.youtube.com

以下、「Python 3 早く来い!」の視点で注目点をピックアップしていきます。

9:00 頃から、 node.js Standard Environment が in a few weeks で登場すると発表

13:00 "idiomatic", You can use any module from the NPM registry you want. There is no API or language restriction. Go や Python みたいに特別な制限は無いようです。

13:33 GAE Standard のインフラの3つの新しい点を紹介していくよ。まずは "Faster than light" ビルド。 gcloud app deploy コマンドが差分アップロードするようになった。 サーバー側で npm install するんだけど、 package.json と package-lock.json に差分がないと npm install はスキップして前の node_modules をそのまま使うよ。

(発表内容から脱線)
さて、 pipenv のドキュメントの Community Integrations に "Mysterious upcoming Google Cloud product (Cloud Hosting)" があります。きっと GAE/Python 3 Standard は pipenv を使って、 npm と同じ "Faster than light" build をするんでしょうね。
(脱線おわり)

14:45 New runtime environment. スタックを上から見ていくと、 "Your code", "node_modules", "node.js" --- これはカスタマイズされてない, "OS packages" --- たとえば headless Chrome なんかがインストールされてる、 "Ubuntu". ってなってる。 node.js 以下は Google が勝手にアップデートする。

16:00 このスタックはサンドボックスで動いている。先週発表した gvisor だ。


今までの GAE Standard Environment は言語ランタイムとかライブラリにカスタマイズしてサンドボックスを提供していたので、言語の追加やアップデートがなかなかされないという欠点がありました。

node.js Standard から利用されている新ランタイムは、 gvisor で作ったサンドボックスのなかで、カスタマイズ無しの言語ランタイムが動くのが魅力です。利用できるライブラリもずっと増えるでしょうし、新しい言語が追加されたり新しいバージョンが利用可能になるのがずっと早くなることが期待できます。

RHEL 7.5 で Python 2.7 が deprecated になりました

Red Hat Enterprise Linux 7.5 がリリースされ、そのリリースノートで "Python 2 has been deprecated" とアナウンスされました。

Chapter 54. Deprecated Functionality - Red Hat Customer Portal

Python 2 has been deprecated

Python 2 will be replaced with Python 3 in the next Red Hat Enterprise Linux (RHEL) major release.

次のメジャーバージョンでは Python 2 が Python 3 に置き換えられるから、 RHEL 7.5 から Python 2.7 が deprecated 扱いになるということです。

Ubuntu 18.04 LTS では main リポジトリから Python 2.7 を排除するのが間に合わなかったのですが、次の RHEL (8?) では Python 2.7 が無くなるようです。

さて、 Python コア開発者による Python 2.7 のサポートは2020年1月1日に終了しますが、主要なLinuxディストリビューションによるサポートがいつまで続くのかがこれでほぼ確定しました。 (Ubuntu 20.04 までには main から Python 2.7 を外すのは既定路線)

2025年を待たずに延命措置も終わるようです。 R.I.P.

Homebrew の Python で何が変わって何がもとに戻ったのか

rcmdnk.com

大分混乱した状態になってしまったので、今年何が変わってきたのか、今回の変更でどこまでもどったのかを整理しておきます。

1/19

python という formula が python コマンドをインストールしなくなりました。 python コマンドを起動すると、通常は /usr/bin/python が起動するようになりました。

1.5.0 — Homebrew

3/2

python という formula が Python 3 になり、 Python 2.7 は python@2 になりました。

python formula (Python 3) が python コマンドをインストールするようになったので、 python コマンドを起動すると通常は Python 3 が起動するようになりました。これが npm の gyp とか色んな所をぶっ壊す変更になっていました。

一方 python@2 formula は keg-only になっていたので、デフォルトではコマンドがインストールされず、必要に応じて brew link --force python@2 などする必要がありました。

コマンド名以外の変更として、多くの formula から depends_on "python" が消されました。今までは依存関係で python (Python 2) がインストールされることが多かったのが、システムの Python を使うようになります。

しかし、 vim など一部の formula では depends_on "python" が残っています。これらは Python 3 に依存するようになりました。

前回の記事

3/10

python@2 が keg-only でなくなりました。 python formula は python3 コマンドだけを提供し、 python@2 formula が pythonpython2 コマンドを提供するようになりました。 python コマンドが /usr/bin/python でなく Homebrew の Python 2 を起動するということで、この点については 1/19 以前の状態にまで戻りました。

1/19 以前の状態と現在の状態を比べると、次のようになります。

  • Python 2 の formula 名が python から python@2 になり、 Python 3 の formula 名が python3 から python になった。
  • 多くのパッケージから depends_on "python" が消えた。依存で Python がインストールされることが減り、代わりに macOSの /usr/bin/python が使われるようになった。 brew install python@2 をすることで macOS ではなく Homebrew の Python 2を使うことも可能で、そうすれば今まで通りの動作になる。
  • vim, macvim など幾つかのパッケージは、 depends_on "python" のまま、 Python 2 依存から Python 3 依存に切り替わった。オプションで Python 2 を使うようにビルドすることもできるが、 bottle が提供されるのはデフォルトの Python 3 依存版。

最終的に一番妥当な形に落ち着いたと思います。

これから 2020 年に向けて、 Python 3 をサポートしているソフトウェアには depends_on "python" を追加して、 Python 2 ではなく Python 3 上で動くようにしていくと良いと思います。

3月1日、Homebrew のデフォルトの Python が Python 3 になります。

以前からアナウンスされていた 通り、 3/1 (日本時間では 3/2 になるかも)にデフォルトの PythonPython 3 に切り替わる予定です。

現在そのプルリクエストがレビュー中です。

github.com

具体的には、今まで "python" という formula は Python2.7 でしたが Python 3.6 になります。 Python 2 をインストールするには brew install python2 もしくは brew install python@2 とします。(これまで使えていた python3 という Formula は python への alias になります。)

何らかの理由で意図的に Python 2 を選択しているユーザー以外は、 brew install python で(推奨される)Python 3をインストールできるようになるので、これは大きな前進です。

また、 Python 2 か 3 のどちらかに依存するパッケージが、今までデフォルトで Python 2 に依存していたのが、 Python 3 に依存するようになります。例えば vim をインストールする時、今までは brew install vim では Python 2 が有効になっていて、 brew install vim --with-python3 とすると Python 3 を有効にできるものの bottle (ビルド済みのバイナリパッケージ)が利用できずソースからビルドになってしまいました。それがこの変更でデフォルトで Python 3 が有効になります。

これで多くの vim, macvim ユーザーが +python から +python3 な vim に移行するので、vim プラグイン作者はより容易に Python 2 を切れるようになります。個人的に一番お世話になっているので例として vim を挙げていますが、多くのアプリで同じことがいえます。