ghqで特定のuser/organizationのリポジトリだけ表示されなくなったら、ディレクトリに .git がいるかも?
homebrewでinstallしたawscli v2の起動時の `SyntaxWarning: "is" with a literal. Did you mean "=="?` に対してできること
homebrewでawscliをinstallしたら、SyntaxWarningが出るようになりました。
aws --version zsh: correct 'aws' to 'as' [nyae]? n /usr/local/Cellar/awscli/2.0.0/libexec/lib/python3.8/site-packages/jmespath/visitor.py:32: SyntaxWarning: "is" with a literal. Did you mean "=="? if x is 0 or x is 1: /usr/local/Cellar/awscli/2.0.0/libexec/lib/python3.8/site-packages/jmespath/visitor.py:32: SyntaxWarning: "is" with a literal. Did you mean "=="? if x is 0 or x is 1: /usr/local/Cellar/awscli/2.0.0/libexec/lib/python3.8/site-packages/jmespath/visitor.py:34: SyntaxWarning: "is" with a literal. Did you mean "=="? elif y is 0 or y is 1: /usr/local/Cellar/awscli/2.0.0/libexec/lib/python3.8/site-packages/jmespath/visitor.py:34: SyntaxWarning: "is" with a literal. Did you mean "=="? elif y is 0 or y is 1: /usr/local/Cellar/awscli/2.0.0/libexec/lib/python3.8/site-packages/jmespath/visitor.py:260: SyntaxWarning: "is" with a literal. Did you mean "=="? if original_result is 0: aws-cli/2.0.0 Python/3.8.1 Darwin/19.0.0 botocore/2.0.0dev4
どうもawscli v1から既知らしい。どういうことだろう?
TL;DR
awscliが依存しているJSONの検索ライブラリ jmetpath
(おそらく --query オプション等で活躍しているのかな?)が number型を is で等値判定しているが、これはPythonの言語仕様ではない。
CPythonの実装ではたまたま可能だったが、Python3.8からはWarning出すようにしたとのこと。
homebrewで入るawscliはv2からデフォルトのPython実行環境をPython3.8にしている。
で、 jmethpath
には3ヶ月前に対応するPRが上がってるんだけどマージされてない。
レビュワーさんの対応が遅れているうちに Travis.CI がPython2.7と3.3をサポートしなくなり、一方で jmethpath
自体は Python2.7と3.3へのサポートを非推奨期間を設けながら続けるつもりらしく、結果CIが腐っている...というように読める。
できること
awscliのシェバンに export PYTHONWARNINGS=ignore
相当のオプションを追記してWarningを黙らせる、っていうのが手っ取り早いかもですね。
もしくは気にしない。Pythonのコンパイラの仕様なのか知らないけど、初回起動時以降は今のところ静かなので....
もっと詳しい方、解釈に違いがあれば教えて下さい🙏
AWS CLI v2のマイナーな互換性チェック(whoami, aws-session-manager-plugin)
チームメンバーにPythonのバージョンを気にしながらインストールしてもらう日々が終わってとっても嬉しいです。
メインの機能を試すのはクラスメソッドさんにお任せして、業務レベルのマイナー互換性を確認していきます。
(ちなみに公式の移行ガイドはこちら)
インストール
公式ドキュメントに沿ってインストール。日本語版ドキュメントにGAが反映されてないけどご愛嬌。
https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/install-cliv2-linux-mac.html
awscli v1は brew uninstall awscli
しました。
whoami
全然いけますね。エイリアスの互換性は一安心。
aws-session-manager-plugin
これも試しましたが、問題なくセッションマネージャーの機能でSSHできました。
感想
基本的な互換性があることを確認できて一安心です。
個人的には、サードパーティーのツールがSSOに対応するのが今後大変そうだな...と心配してしまいました。
aws-vault
や awslogs
はなければ業務が詰むレベルで常用しているので、廃れずにアップデートが進むように応援していきたいところです。
pyenv のエラー line 21: /usr/local/Cellar/pyenv/1.2.15/libexec/pyenv: No such file or directory → zshに切り替えたときに pyenv initを追記し忘れ
TL;DR
pyenvのshimsディレクトリは、シェル起動時の pyenv init コマンドで作成されるようです。
(もちろん毎回作っていてはたまらないのでいい感じに冪等な仕組みがあるのでしょうが)
zshに切り替えたときに pyenv (あと rbenv)の設定を忘れていました。
それで昨日Ruby動かなかったのか...
if command -v pyenv 1>/dev/null 2>&1; then eval "$(pyenv init -)" fi eval "$(rbenv init -)"
経緯
実はzshに切り替えたあともしばらくは動いていたんですが、 brew update pyenv したときにだめでした。
.../shims/python のファイル内にpyenvのパスをバージョン名指しで書いているスクリプトがあり、それが pyenv initで最新に保たれるからです。
こういうの素早く気付けるように、dotfilesを一つのディレクトリでいつでも見やすくしておくのは大事ですね。
しかし環境切替時は互換テストすべきだな。反省...。
mac(BSD)とLinuxでcpコマンドの動作が違うのにハマった → core utilsをGNUに総取り替え
TL;DR
やったこと
Brewfile
にcoreutils
ほかutilityを追加$PATH
と$MANPATH
を修正
brew install coreutils findutils gnu-tar gnu-sed gawk gnutls gnu-indent gnu-getopt grep export PATH="/usr/local/opt/findutils/libexec/gnubin:$PATH" export PATH="/usr/local/opt/gnu-tar/libexec/gnubin:$PATH" export PATH="/usr/local/opt/gnu-sed/libexec/gnubin:$PATH" export PATH="/usr/local/opt/gawk/libexec/gnubin:$PATH" export PATH="/usr/local/opt/gnutls/libexec/gnubin:$PATH" export PATH="/usr/local/opt/gnu-indent/libexec/gnubin:$PATH" export PATH="/usr/local/opt/gnu-getopt/libexec/gnubin:$PATH" export PATH="/usr/local/opt/grep/libexec/gnubin:$PATH" export MANPATH="/usr/local/opt/coreutils/libexec/gnuman:$MANPATH" export MANPATH="/usr/local/opt/findutils/libexec/gnuman:$MANPATH" export MANPATH="/usr/local/opt/gnu-tar/libexec/gnuman:$MANPATH" export MANPATH="/usr/local/opt/gnu-sed/libexec/gnuman:$MANPATH" export MANPATH="/usr/local/opt/gawk/libexec/gnuman:$MANPATH" export MANPATH="/usr/local/opt/gnutls/libexec/gnuman:$MANPATH" export MANPATH="/usr/local/opt/gnu-indent/libexec/gnuman:$MANPATH" export MANPATH="/usr/local/opt/gnu-getopt/libexec/gnuman:$MANPATH" export MANPATH="/usr/local/opt/grep/libexec/gnuman:$MANPATH"
どうしてやったのか
dotfilesを $HOME
に展開する上で、cpコマンドの-lオプションが便利だからです。
このオプション、BSDのcpコマンドにはなかったので...
結果
無事にGNUベースに置き換え成功しました!
Intellij の Convert Code From Java は文法にエラーがあると動かない
TL;DR
このように、 ...
でコードを省略するなど、Java的に正しくないコードの場合は動かないので注意。
String expected = "EXPECTED"; ... Assert.assertEquals(expected, test());
むむ?と思ったら、一行づつコピペして試すべし。
文法的にエラーがない場合
設定で機能をオフにしている可能性もあるので要チェック
mysql-connector-pythonはSQLのSyntax Errorを拾ってくれない(ように見える)
いずれPR送って直したい。公式ライブラリのエラーハンドリングを疑ったことはなかったので...
TL;DR
connectionクラスでせっかく例外を投げているのに、
github.com
cursorクラスで雑なキャッチをして台無しにしている。
詳細
例えば、date型とdatetime文字列を比較しているSQLがあったとする。
クエリはprepared_statementとして処理されるので(Pythonが検証するわけでない)、MySQLからのSyntax Errorが返ってくる。
prepared_statementの生成は一応try-exceptされているが、レスポンスはサーバーから返ってきた文字列次第であるせいか?キャッチの仕方が極めて雑。
ライブラリなので標準出力もしていない。
try: self._prepared = self._connection.cmd_stmt_prepare(operation) except errors.Error: self._executed = None raise
結果、呼び出し側でtry-exceptを忘れてしまい困ることがありました。備忘。