なるほど、Pythonのパッケージングに関して、公式情報に相当する情報があるのですね。勉強になります。

それから、言及されているチュートリアルとサンプルプロジェクトのどちらも設定を書くのがsetup.pyではなくpyproject.tomlなのですね。 自分でも少し調べてみたのですが、python.orgにあるガイドには、「（パッケージングの設定には）pyproject.tomlファイルを使うのが標準的な慣習です。」と書いてあり、Zennの記事でも「現在でも歴史的経緯から setup.py のみで設定を行っているプロジェクトは多く存在しますが、このような構成は現在では非推奨」、「setup.pyを設定ファイルの一部として用いる場合であってもpyproject.tomlは配置するのが現在の標準的なセットアップ方法」と書いてある記事を見つけました。

どうやら、Pythonパッケージにはpyproject.tomlを用意すべし、pyproject.tomlを起点にしてPythonパッケージをビルドすべし、というのが公式見解のようですね。コマンドラインからsetup.pyを直接実行するやり方はlegacy、つまり、廃止予定とのことですし。

Pythonのライブラリを自作するときに、フォルダ構成や設定ファイルの書き方について知りたくなることがあります。ライブラリを公開するかどうかやどの程度きっちり作るかなど状況は様々だと思いますが、ソフトウェアの規模が大きいときやあちこちから呼び出す関数を整備するときなどに、ライブラリやライブラリに準じるものを作成することはよくあることだと思います。そういうときにどういう作り方が行儀の良いやり方なのかを探していて見つけた情報が以下のものです。

Python公式サイトのパッケージングに関するチュートリアル

https://packaging.python.org/ja/latest/tutorials/packaging-projects/

Pythonの公式サイトである「python.org」に置いてある文書ですので、信頼できる情報なのだと思います。

PyPAのサンプルプロジェクト

https://github.com/pypa/sampleproject

Pythonでのパッケージングに関するとりまとめを行っている組織であるPyPAが出しているサンプルですので、信頼できるのではないかと思います。

同じコマンドをパパッと使い回す方法として便利なときがあるかもしれませんね。

それから、.bash_historyを後から見たり検索したりするなら、こういうコメントが残っていると実は便利なのかも。

よく使うコマンドはaliasやシェルスクリプトの形で保存し再利用するのが王道かと思いますが、
「#」」を使ったコメントをコマンドの後ろに付けることで、コマンドを手軽に再利用する方法もあります。

例えば、以下のようにコマンドの後ろにコメントを付けておきます。

cd ~/foo/bar/baz #cfbb

すると今後は、このコマンドをそのまま再実行したいときには、C-rのあと#cfbbと入力してEnterで再実行できます。

ちなみに、コマンド全体が同じではなく、引数などの部分をそのときそのときで変えたい場合には、 先ほどの操作から続けて、C-eで行末に移動し、M-bとM-fで単語単位で移動して、M-dかC-wで単語単位で削除して、新たな内容を入力、といった形で対応することも出来はします。 もちろん、こういった操作がややこしい感じになるなら、素直にaliasかシェルスクリプトの活用の方が良いのではないかと思いますので、このコメントを利用した方法が活躍する場面は、全く同じコマンドを繰り返す場合だと思います。

無料版のCopilotでもフルタイムでGPT-4 Turboが利用できるように

2024/2/13頃から、無料版のユーザーであっても、いつでもCopilotでGPT-4 Turboが利用可能になったとのこと。 ただし、モードによって違いがあるので注意。「よりバランスよく（Balanced）」のモードではGPT-4 Turboが使われるのは限定的。一方で、「より創造的に（Creative）」と「より厳密に（Precise）」のモードではほぼ確実にGPT-4 Turboが使われるとのこと。

情報ソース

Microsoft Copilotのニュースなどを全般的に扱うTopicです。Copilotに関するちょっとした情報共有などでご利用ください。

2023/12/25にcommonmarker v1.0.0がリリースされました。 それから4ヶ月以上が経過していますが、v1.xを採用せずにv0.xに留まっているライブラリやプロジェクトが多いように見受けられます。

たとえば、 jekyll-commonmarkのgem指定や commonmarker-rougeのgem指定は、 2024/05/13現在ではv0.xになっています。

v0.xで出来ていた編集操作がv1.xではまだ出来ない？

commonmarkerにMarkdownを入力して、出力されたHTMLをそのまま使う分には現在のv1.xで十分でしょう。 しかし、スタイル変更やJavaScriptによる機能付与などで、出力されるHTMLを多少変更したいことがあります。 v0.xではこういうときに使えるものとして、任意のHTMLを挿入する方法があったのですが、少なくともこのv0.xの方法はv1.xでは出来なくなったようです。

Pluginの活用か何かで、v1.xでもv0.xと同じように、出力のHTMLを部分的に好き勝手な形に編集することは出来るのでしょうか？ ご存じの方がいらっしゃいましたら、コメントをいただけると嬉しいです。

別デバイスからhttpsでrails serverにアクセスする方法

前述の方法で別デバイスからhttpでアクセスできるようになりますが、httpsでアクセスする必要がある場合には、 local-ssl-proxyを使ってhttpsをhttpに振り向けることで、httpsアクセスが可能になります。具体的な方法は以下をご覧ください。 なお別デバイスからhttpsでアクセスするには、前述のポートフォワーディングとファイアウォールの設定をhttpsのポート番号で行う必要があります。

• local-ssl-proxyを使ってhttpsでhttp://localhost:3000/へアクセスする方法

背景

Webの機能には、httpsでアクセスしているときにしか利用できないものがあります。 例えば、navigator.clipboardを用いてクリップボードへ書き込む機能はhttpsでアクセスしているときにのみ利用可能です。 ローカル環境においてhttpで走っている開発中のアプリに対して、こういった機能をテストするために、httpsでアクセスしたい場合があります。

ローカルでhttpsアクセスをhttpアクセスへ振り向ける方法

以下のコマンドを実行すれば、httpで走っている（ http://localhost:3000/ ）アプリに、ブラウザからhttps（ https://localhost:3001/ ）からアクセスできるようになります。

npx local-ssl-proxy --source 3001 --target 3000

なお、アプリが走っているPCとは別のデバイスからアクセスする場合には、httpのポートのために行ったポートフォワーディングやファイアウォールの設定がhttpsのポートにも必要となります。

• （設定方法の参考資料） WSL2上にてrails serverで立ち上げたサーバに別デバイスからのアクセスを可能にする方法

余談その1

Copilot先生によれば、httpで走っているアプリにhttps相当でアクセスするための別の方法としては、以下のものがあるそうです。

• localtunnelなど、ローカルで走っているアプリをインターネットに公開するサービスを利用してしまう。
• Chrome DevToolsのリモートデバッグ機能を利用する。

なお、Copilot先生の回答全文はこちらです。

余談その2

local-ssl-proxyは、Copilot先生に教えてもらいました。Google検索ではlocal-ssl-proxyにはたどり着いていませんでした。

__init__.pyとモジュール・パッケージ・名前空間の関係について、以下の記事が分かりやすかったです。単に「こう書けば動く」ではなく、概念が説明されていてありがたいです。

• Python の init.py とは何なのか