目次: Python
Pythonの仮想環境(venv)は便利ですが、移動したりリネームすると使えなくなる罠があります。変な仕様ですね。
使えなくなる理由はいくつかありますが、そのうちの1つはvenv/binの下にあるPythonスクリプトのshebangにPythonインタプリターの絶対パスが書かれているからです。なぜこんなことになるのかインストーラ(pip)の実装を軽く調べました。
調べ方もメモしておきます。実験用のvenv環境を作成します。
$ python -m venv venv $ source venv/bin/activate
実験するときはwheelパッケージをinstall/uninstallするのが動作も速いしやりやすいです。wheelでなくともbinの下に実行ファイルをインストールするパッケージであれば何でも良いです。ただし例えばsimplejsonパッケージはbinの下に何もインストールしないので今回の調査には適しません。
(venv) $ pip install wheel (venv) $ pip uninstall -y wheel
あとはpipパッケージのスクリプトにprint文を入れつつinstall/uninstallを繰り返し、スクリプトのどこで何をしているか調べるだけです。
Pythonスクリプトのshebangに絶対パスを書く処理は、pipの下記の部分です。
# venv/lib/python3.12/site-packages/pip/_vendor/distlib/scripts.py
def _make_script(self, entry, filenames, options=None):
post_interp = b''
if options:
args = options.get('interpreter_args', [])
if args:
args = ' %s' % ' '.join(args)
post_interp = args.encode('utf-8')
shebang = self._get_shebang('utf-8', post_interp, options=options) #★★shebangを得る★★
script = self._get_script_text(entry).encode('utf-8')
scriptnames = self.get_script_filenames(entry.name)
if options and options.get('gui', False):
ext = 'pyw'
else:
ext = 'py'
self._write_script(scriptnames, shebang, script, filenames, ext) #★★スクリプトをファイルに書き込む★★
...
def _get_shebang(self, encoding, post_interp=b'', options=None):
enquote = True
if self.executable:
executable = self.executable
enquote = False # assume this will be taken care of
elif not sysconfig.is_python_build():
executable = get_executable() #★★インタプリタ実行パスを得る★★
elif in_venv(): # pragma: no cover
executable = os.path.join(sysconfig.get_path('scripts'), 'python%s' % sysconfig.get_config_var('EXE'))
else: # pragma: no cover
if os.name == 'nt':
# for Python builds from source on Windows, no Python executables with
# a version suffix are created, so we use python.exe
executable = os.path.join(sysconfig.get_config_var('BINDIR'),
'python%s' % (sysconfig.get_config_var('EXE')))
else:
executable = os.path.join(
sysconfig.get_config_var('BINDIR'),
'python%s%s' % (sysconfig.get_config_var('VERSION'), sysconfig.get_config_var('EXE')))
...
# venv/lib/python3.12/site-packages/pip/_vendor/distlib/util.py
def get_executable():
# The __PYVENV_LAUNCHER__ dance is apparently no longer needed, as
# changes to the stub launcher mean that sys.executable always points
# to the stub on OS X
# if sys.platform == 'darwin' and ('__PYVENV_LAUNCHER__'
# in os.environ):
# result = os.environ['__PYVENV_LAUNCHER__']
# else:
# result = sys.executable
# return result
# Avoid normcasing: see issue #143
# result = os.path.normcase(sys.executable)
result = sys.executable #★★実行中のpythonインタープリタの絶対パスを得る★★
if not isinstance(result, text_type):
result = fsdecode(result)
return result
コメントに書いた通り、実行中のPythonインタープリタの絶対パスsys.executableからshebangを生成します。この処理はvenv/bin以下にインストールされるPythonスクリプト全てに適用され、venv/bin以下のスクリプト全てにPythonの絶対パスが書かれるようです。
目次: ゲーム
首都高バトルSteam版を買いました。首都高バトルシリーズは2006年の「首都高バトルX」が出てそれっきりだったので、ほぼ20年ぶりに帰ってきたんですね。
私は「首都高バトル0(2001年)」辺りで脱落していたので、20年どころか25年ぶりでした。超懐かしい……。
首都高を走っている車やライバル(名前がある奴ら)にパッシングしてケンカを吹っ掛けてレースして、レースに勝てば賞金(?)がもらえます。賞金は車をチューンしたり、車を乗り換えたりするために使います。実に治安が悪い首都高ですね。
と思いきや主人公側からは無限にケンカが売れますが、相手から売ってくることはありません。治安が悪いのは主人公だけだったようです。
走れるコースは、
このあたりです。C2はコースにありません。C1の西側や北側にいく路線(池袋線とか)もありません。
基本的には道路上に居る車なら全員とバトル可能ですが、負けたくない場合はタクシーとバトルするのはやめましょう。
名無しカーのくせにめちゃくちゃ速くて、序盤に手に入る車ではまずもって勝てません。
アーリーアクセス版であるせいか、Twitterを見ていると色々バグってる報告がチラホラありますが、普通に遊んでいる分には全く気になりませんでした。
Ansibleのencrypt_stringで作成したencrypted variablesの中身が見たかったので、無理やりdecryptコマンドに通す方法をメモしておきます。
$ ansible-vault encrypt_string --name "var_a" 'hogehoge' > var_a.txt New Vault password: a Confirm New Vault password: a $ cat var_a.txt var_a: !vault | $ANSIBLE_VAULT;1.1;AES256 37363466383930393938653532613234373138353964386136303862663465623437373462366237 3562326438326330306561373335346435313230383236660a383736346135396531343939623533 63653563663336346536333134326165383265303033383534393531666363666362326333613734 3635656466323266320a646463333737666230653337363730356434656430373630656262663433 6436
このままだとansible-vaultはdecryptしてくれませんので、先頭行と行頭のスペースを消して普通のvaultファイルにします。
$ANSIBLE_VAULT;1.1;AES256 37363466383930393938653532613234373138353964386136303862663465623437373462366237 3562326438326330306561373335346435313230383236660a383736346135396531343939623533 63653563663336346536333134326165383265303033383534393531666363666362326333613734 3635656466323266320a646463333737666230653337363730356434656430373630656262663433 6436 $ ansible-vault decrypt var_a.txt Vault password: a Decryption successful $ cat var_a.txt hogehoge
戻りました。もっとスマートな方法がありそうですが、とりあえず1個見たいだけのときに良く使っています。
Thunderbird 115.0(Supernova, 2023/07/11リリース)から導入されたUnified Toolbarですが、使わないのに最上段の一番良いスペースにずっと表示され続けていて邪魔です。だけど利用者(or開発者?)には気に入られているのか、安定版がThunderbird 128系に変わってもUnified Toolbarはウインドウ最上段に鎮座し続けています。
Unified Toolbarを消せないかなと思い、とりあえずToolbarのボタンを全てRemoveしました。しかしツールバーそのものは消えなくて虚無が残ります。
Unified Toolbarのボタンは消せるが、Unified Toolbarそのものは消せない
何か他の方法は?と調べたら割とすぐに「消すの無理」と回答されているフォーラムQA(How to remove the new toolbar in version 115? - Thunderbird Support Forum - Mozilla Support)を見つけてしまいました。うーん、イマイチだ〜。
GUIはイマイチでも、ThunderbirdのUXの神髄はメールの削除速度にあると思います。
昔のThunderbirdはもう本当にメール削除が遅くて、途中で寝てしまえるレベルでした。たぶん秒間10〜20通程度だったと記憶しています。しかし正確な時期はわかりませんが、しばらく前にメール削除の速度が超々々々改善されまして、今では1,000通overを一瞬で削除できるようになっています。
メール削除スピード改善は自分にとっては最高のUX改善でした。GUIなどの他のイマイチな点が全て霞むレベルです。
GNOME48からフォントが変わるニュースを見ていて、フォントを作成するのが割と簡単な英語圏にしては、Cantarellを15年も使っていたのは珍しい?んでしょう。結構息が長かったんだなあと思います。
フォントが長く使われる傾向に関しては日本語フォントもたいがいだよなあ?と思ったのでWindowsの日本語フォント変遷をリストアップしてみました。
やはりWindowsの日本語フォントはみんな息が長いです。次世代にバトンを渡すまでの期間だけ見ても、MSゴシック13年、メイリオ9年、游ゴシックも10年経ったんですね。Windowsの次バージョンが出るか出ないか定かじゃないですけど、もし次があったとしたらフォントを変えてきそうですね。