さわらブログ

さわら(@xhiroga)の技術ブログ

`subscription for the service`以前に作成した AWSのIAM UserのAccess Keyは一旦捨てたほうがいい?

The AWS Access Key Id needs a subscription for the service エラーを受けて、サインアップのプロセスがすべて完了していることをチェック→再度アクセスキーで作業したがエラー。 アクセスキーを再作成したら動きました。

ghqで特定のuser/organizationのリポジトリだけ表示されなくなったら、ディレクトリに .git がいるかも?

タイトルで言い切った。

TL;DR

ghq list で、会社のorganizationのリポジトリが表示されなくなりました。
よく見ると、代わりに organization の名前のリポジトリがあるような...?

→ 会社のorganizationの直下に .git フォルダがいました。消したら正常に動作しましたよ!

実装について

たぶんこの辺だと思うんですが、 Go言語が読めるようになったら再トライします。

github.com

homebrewでinstallしたawscli v2の起動時の `SyntaxWarning: "is" with a literal. Did you mean "=="?` に対してできること

homebrewでawscliをinstallしたら、SyntaxWarningが出るようになりました。

f:id:hiroga_cc:20200215081549p:plain

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から既知らしい。どういうことだろう?

github.com

TL;DR

awscliが依存しているJSONの検索ライブラリ jmetpath (おそらく --query オプション等で活躍しているのかな?)が number型を is で等値判定しているが、これはPythonの言語仕様ではない。
CPythonの実装ではたまたま可能だったが、Python3.8からはWarning出すようにしたとのこと。

docs.python.org

homebrewで入るawscliはv2からデフォルトのPython実行環境をPython3.8にしている。

で、 jmethpath には3ヶ月前に対応するPRが上がってるんだけどマージされてない。 レビュワーさんの対応が遅れているうちに Travis.CI がPython2.7と3.3をサポートしなくなり、一方で jmethpath 自体は Python2.7と3.3へのサポートを非推奨期間を設けながら続けるつもりらしく、結果CIが腐っている...というように読める。

github.com

できること

awscliのシェバンに export PYTHONWARNINGS=ignore 相当のオプションを追記してWarningを黙らせる、っていうのが手っ取り早いかもですね。 もしくは気にしない。Pythonコンパイラの仕様なのか知らないけど、初回起動時以降は今のところ静かなので....

もっと詳しい方、解釈に違いがあれば教えて下さい🙏

AWS CLI v2のマイナーな互換性チェック(whoami, aws-session-manager-plugin)

AWS CLI v2がGAされました!わーい!

f:id:hiroga_cc:20200213091056p:plain

チームメンバーにPythonのバージョンを気にしながらインストールしてもらう日々が終わってとっても嬉しいです。

メインの機能を試すのはクラスメソッドさんにお任せして、業務レベルのマイナー互換性を確認していきます。

(ちなみに公式の移行ガイドはこちら)

インストール

公式ドキュメントに沿ってインストール。日本語版ドキュメントにGAが反映されてないけどご愛嬌。
https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/install-cliv2-linux-mac.html

awscli v1は brew uninstall awscli しました。

whoami

全然いけますね。エイリアスの互換性は一安心。

f:id:hiroga_cc:20200213091848p:plain

aws-session-manager-plugin

これも試しましたが、問題なくセッションマネージャーの機能でSSHできました。

感想

基本的な互換性があることを確認できて一安心です。

個人的には、サードパーティーのツールがSSOに対応するのが今後大変そうだな...と心配してしまいました。
aws-vaultawslogs はなければ業務が詰むレベルで常用しているので、廃れずにアップデートが進むように応援していきたいところです。

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に総取り替え

f:id:hiroga_cc:20200115072013p:plain
cp (BSD)

TL;DR

apple.stackexchange.com

やったこと

  • Brewfilecoreutils ほか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コマンドにはなかったので...

github.com

結果

f:id:hiroga_cc:20200115073106p:plain
cp (GNU)

無事にGNUベースに置き換え成功しました!

Intellij の Convert Code From Java は文法にエラーがあると動かない

TL;DR

このように、 ... でコードを省略するなど、Java的に正しくないコードの場合は動かないので注意。

String expected = "EXPECTED";
...
Assert.assertEquals(expected, test());

むむ?と思ったら、一行づつコピペして試すべし。

文法的にエラーがない場合

設定で機能をオフにしている可能性もあるので要チェック

stackoverflow.com