2023年 3月 の投稿一覧

GitHubのRSA鍵が変更された!鍵交換の対応手順

こんにちは、ウチイダです。

GitHubのリモートリポジトリへpush しようとしたところ、以下のようにエラーが表示されました。

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
SHA256:uNiVztksCsDhcc0u9e8BujQXVUpKZIDTMczCvj3tD2s.
Please contact your system administrator.
Add correct host key in ~/.ssh/known_hosts to get rid of this message.
Offending RSA key in ~/.ssh/known_hosts:1
  remove with:
  ssh-keygen -f "~/.ssh/known_hosts" -R "github.com"
RSA host key for github.com has changed and you have requested strict checking.

ローカルに保持している接続先情報と違うサーバーにつながったよ、とのこと。

中間者攻撃かもしれないと書かれており、ちょっとドキッとしますよね。。。

調べてみたところ、公式からアナウンスが出ていました。

GitHubサーバーの秘密鍵を、公開リポジトリに置いてしまったのとこと…

短時間ってどのくらいなんでしょうね…?

このセキュリティインシデントに対する措置として鍵を取り換えたということのようです。

新しい内容で接続できるように変更しておきます。

やることは特に難しくなく、古い情報を破棄して新しい情報に差し替えるだけです。

# 古い鍵情報の破棄
$ ssh-keygen -R github.com
/home/y-uchiida/.ssh/known_hosts updated.
Original contents retained as /home/y-uchiida/.ssh/known_hosts.old

# 新しい鍵情報を追加
$ ssh -T github.com
The authenticity of host 'github.com (20.27.177.113)' can't be established.
ECDSA key fingerprint is SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM. # 表示される鍵情報が正しいものか確認
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes # yes を入力
Warning: Permanently added 'github.com' (ECDSA) to the list of known hosts.
Hi y-uchiida! You've successfully authenticated, but GitHub does not provide shell access.

アナウンスだと、known_hosts に接続先情報を手動追加、もしくはコマンドで追加するように記載されていましたが、少し違う方法を取りました。

ssh -T github.com で接続テストをすると、known_hosts に接続先の情報がなければ確認を出してくれます。

ここでyes を入力すれば、接続先情報がknown_hosts に登録されます。

以下のページで、GitHubの公開鍵が一覧化されています。

https://docs.github.com/ja/authentication/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints

接続確認時に表示された公開鍵が、いずれかに一致していれば問題ありません。

以上です。あなたのお役に立てれば幸いです。

Python, Djangoをきちんと使いたい_05: Flake8 でコーディングルール違反を自動チェック

皆さまこんにちは、ウチイダです。

時間を見つけてはDjango で中規模以上のアプリケーションを開発するための環境構築について調べています。

前回の記事はこちら。

ウチイダの作業環境は以下です。

  • Windows 11 21H2
  • WSL2 Ubuntu20.04
  • GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu)

以降の内容は、この環境にPython/Djangoの開発環境を導入していく手順メモとなります。

PEP 8 遵守はFlake8 におまかせ

さて、前回も述べたとおりですが、コーディングルールを決めたり、目視・手動でルールを順守するのはとても大変です。プログラムを書くときは、ロジックの実装のことだけ考えていたいものです。

PythonにはPEP 8というデファクトスタンダードなスタイルガイドがありますので、これにきっちり合わせていきたいです。

書いたプログラムがPEP 8 のルールに沿っていない場合に教えてくれるのが、Flake8 です。

厳密には、コードチェックのためのいくつかのパッケージを含んでいますが、今回はPEP 8のチェックのために利用します。

パッケージのインストール

過去の記事に続いて、poetry でインストールしていきます。

(python-flake8-sample-py3.11) $ poetry add --dev flake8
Creating virtualenv flake8-sample in /home/y-uchiida/python/flake8_sample/.venv
The --dev option is deprecated, use the `--group dev` notation instead.
Using version ^6.0.0 for flake8

Updating dependencies
Resolving dependencies... (0.2s)

Writing lock file

Package operations: 4 installs, 0 updates, 0 removals

  • Installing mccabe (0.7.0)
  • Installing pycodestyle (2.10.0)
  • Installing pyflakes (3.0.1)
  • Installing flake8 (6.0.0)

CLI から実行する

それではFlake8 を使ってみます。

flake8 <チェック対象のファイルパス> で実行できます。

PEP 8に沿ってない内容のスクリプトを書いて、、、

if 1 is 1:  # リテラルの比較に is は使わない
  print('always true')  # インデントはスペース4つにする

Flake8 で検査します。

(python-flake8-sample-py3.11) $ flake8 flake8_test.py
flake8_test.py:1:4: F632 use ==/!= to compare constant literals (str, bytes, int, float, tuple)
flake8_test.py:2:3: E111 indentation is not a multiple of 4

しっかりエラーを出してくれました!

Flake8 はチェックツールなので、自動での修正はしてくれません。列挙された内容を見て、それぞれ必要な修正をしていきましょう。

VSCode のFlake8 拡張

とはいえ、CLIでコマンドを実行して、それを確認しながら修正するのは大変です。

コードを記述している段階で、エディタ上にエラーが出てくる方が簡単です。

というわけで、VSCodeに拡張機能を導入していきます。

Microsoft が提供している拡張機能があるので、これを利用します。

Flake8 の拡張機能を導入

拡張機能の説明文によると、この拡張機能を導入するだけで、Flake8でのコードチェックが使えるようになるみたいです。

プロジェクトで選択されているPython環境にFlake8 がインストールされていない場合だけ、拡張機能がバンドルしているflake8 (5.0.4)が利用されるとのこと。

CIで利用するにはパッケージを入れておく必要がありますが、書き捨てのちょっとしたプロジェクトなら、拡張機能を入れておくだけでいいかもしれません。

まあ、そういう場合はそもそもコードチェックツール使う必要もないのかもしれませんが…

設定値の変更

念のため、VSCode でFlake8がしっかり動作するように、設定を変更していきます。

まずはデフォルトのリンターを変更します。

デフォルトでPylint が有効になっているので、これを無効にしておきます。

VSCode の設定をひらいて、python.linting.pylintEnabled のチェックを外します。

設定でPylint を無効にする

代わりに、Flake8 を有効にします。

python.linting.Flake8 Enabled にチェックをつけます。

設定でFlake8 を有効にする

これで、基本的にはOKです。

こんな感じで、エディタ上とProblemsパネルにスタイル違反を表示してくれます。

VSCode 上でPEP8 に沿っていない記述がわかる

これで、問題のあるコードがすぐにわかります。

Blackとの併用の設定

さて、ここまででFlake8 の設定自体は終わりです。

しかし、「妥協を許さないフォーマッター」ことBlackと併用する場合、ルールの食い違いが起こってしまいます。

Black はルールの変更ができないので、Flake8 のルールを変更してあげる必要があります。

Black のドキュメントに対応方法が書いてあるので、それに従えばOKです。

https://black.readthedocs.io/en/stable/guides/using_black_with_other_tools.html

設定ファイルとして.flake8 か、setup.cfg か、tox.ini を用意して、以下のように記述します。

すでに上記のファイルがある場合は、追記してください。

[flake8]
max-line-length = 88
extend-ignore = E203

残念ながらFlake8 はpyproject.toml の設定情報を読んでくれません。

pyproject-flake8 という、Flake8 のラッパーを導入することでpyproject.toml に設定を書くことができるようです。

.flake8 ファイルを使えば、Flake8 の設定ファイルであることが一目瞭然なので、あえてこのままでもいいのでは、と考えています。

ちなみに、上記の設定例ではmax-line-length が88になっていますが、1行88文字は意外と短いです。

Blackでも唯一変更できるルールなので、設定値を100とか120に変更する場合もあると思います。

その場合は、Flake8のほうもその設定に合わせておきましょう。

まとめ

PEP8 のさまざまなルールを瞬時にチェックしてくれるFlake8のご紹介でした。

コードスタイルの乱れは風紀の乱れ、ということで、勝手に風紀委員と思っています。

Flake8 には、maccabe というコードの複雑度を判定するパッケージも含まれています。

これも使ってみたいところですが、運用方法がややこしくなりそうなので、今のところは見送っています。

以上です。あなたのお役に立てると嬉しいです。

参考資料

https://qiita.com/fehde/items/723b619013dc86008acc

https://itc-engineering-blog.netlify.app/blogs/black-flake8

Python, Djangoをきちんと使いたい_04: Black を入れてフォーマットをかける

皆さまこんにちは、ウチイダです。

時間を見つけてはDjango で中規模以上のアプリケーションを開発するための環境構築について調べています。

前回の記事はこちら。

ウチイダの作業環境は以下です。

  • Windows 11 21H2
  • WSL2 Ubuntu20.04
  • GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu)

以降の内容は、この環境にPython/Djangoの開発環境を導入していく手順メモとなります。

Blackで、フォーマッターの下の平等を実現する

コードスタイルの一貫性を保つのは、読みやすさを維持するために重要です。でも、コーディングルールをきちんと決めるのがまず大変だったりします。

また、コーディングルールを気にかけながらコードを書くのはつらいです。

こういうのはツールに頼ってしまいたい部分ですね。

今回はBlack を利用して、自動フォーマットをかけるところまでやってみたいと思います。

パッケージの導入

過去の記事に続いて、poetry でインストールしていきます。

$ poetry add --dev black
Creating virtualenv python-black-sample in /home/y-uchiida/develop/python-black-sample/.venv
The --dev option is deprecated, use the `--group dev` notation instead.
Using version ^23.1.0 for black

Updating dependencies
Resolving dependencies... (0.5s)

Writing lock file

Package operations: 6 installs, 0 updates, 0 removals

  • Installing click (8.1.3)
  • Installing mypy-extensions (1.0.0)
  • Installing packaging (23.0)
  • Installing pathspec (0.11.0)
  • Installing platformdirs (3.1.0)
  • Installing black (23.1.0)

これだけでセットアップ完了です!

CLIから実行する

black <修正対象のファイルパス> で、自動フォーマットを実行できます。

こんな感じで、みるからにガタガタなファイルを作って…

def main():	
      print("this"      +      "is"      +      'main')
      return            0

コマンドを実行!

(python-black-sample-py3.11) $ black format_test.py 
reformatted format_test.py

All done! ✨ 🍰 ✨
1 file reformatted.

以下のように修正されました。

def main():
    print("this" + "is" + "main")
    return 0

Black の特徴

基本的な使い方がわかったところで、Black について知っておきましょう。

Blackは、ルールがとても厳格というか、選択の余地がないフォーマッターです。

ドキュメントの冒頭で、こんなことを書いています。

By using Black, you agree to cede control over minutiae of hand-formatting. In return, Black gives you speed, determinism, and freedom from pycodestyle nagging about formatting. You will save time and mental energy for more important matters.

https://black.readthedocs.io/en/stable/

ざっくり意訳すると、Blackが提供するコードスタイルに従うことで、手作業でのフォーマットや、書式設定をしなくてよくなるよ!ということです。

コードスタイルにこだわりがある人はとっつきづらいかもしれませんが、チーム開発では自動で統一されるメリットは大きいですね。

ちなみに、設定ファイルでデフォルトから変更できるルールは、2023年3月時点では1行あたりの文字数だけです。

公式リポジトリのpyproject.toml にも、それしか設定項目がありません。

https://github.com/psf/black/blob/main/pyproject.toml

「妥協を許さないフォーマッター」というだけのことはあります。

VSCode のBlack 拡張機能

次はVSCodeでBlackを利用する場合の設定手順です。

設定といっても、拡張機能をインストールするだけでした。

VSCode用 Black 拡張機能

Black のパッケージをインストールしていなくても、この拡張機能を有効にすればOKです。

preview ってついているのが若干気になりますが、基本的な動作には問題なさそうでした。

拡張機能を入れただけだと、Blackのルールでフォーマットされないので、少しだけ設定を編集します。

@lang:python defaultFormatter で検索すると表示される項目を、Black Formatter に指定します。

Black Formatter をデフォルトに指定

また、 python.formatting.provider のデフォルトがautopep8 になっているので、 black を指定しておきます。

autopep8 から black に変更

また、ファイルの保存時にblack でフォーマットがかかるように、Format On Saveの設定も有効にしておきます。

Format On Save のチェックをオンにする

これで、VSCodeの設定は完了です!

スペースがガタガタなファイルを、VSCode で保存してみると、きっちりそろえてくれます✨

まとめ

導入するだけですぐに使えるフォーマッター、Blackのご紹介でした。

コードスタイル疲れのない、快適なPythonライフを送れそうです。

OSSでの利用数もすごく増えているようで、Blackに慣れておくといろいろなPython のコードが読みやすくなるかもしれません。

以上です。あなたのお役に立てると嬉しいです。

参考資料

https://nobunobu1717.site/?p=1845

https://nujust.hatenablog.com/entry/2022/07/24/114715