python / python/importlib_metadata

Revisit relationship between Distribution and PathDistribution

オープン
#445 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

help wanted
主要言語
Python
スター
142
フォーク
97
PR マージ指標
30日以内にマージされた PR はありません

説明

Should Distribution objects expose a method to resolve paths?

Yes, that is one solution. There is already .locate_file() which is not far off, except that its implementation in PathDistribution precisely removes the metadata directory that we need in this case.

More generally, I wonder if there is just a tad too much coupling between the Distribution and PathDistribution classes?

There is a mix of abstract and concrete methods in the Distribution base class, and several of the concrete methods seem fairly tightly bound to the PathDistribution subclass. For example, the at() static method creates and returns a PathDistribution instance outright, and the metadata(), entry_points(), files(), and requires() methods are all implemented with assumptions as to which files should be available and that the organization should resemble a dist-info or egg-info distribution.

Now, there is (AFAICS) only the one (PathDistribution) subclass of Distribution available in this project, and I don't really have enough experience with this project or its users to really imagine what other Distribution subclasses would or could exist in the wild.

Still, I would suspect that a subclass that was sufficiently different from PathDistribution to rather prefer subclassing Distribution directly, would then find itself not merely implementing the read_text() an locate_file() abstract methods, but would probably also need to _re_implement several of metadata(), entry_points(), files(), or requires() as well.

Hence, I would raise the question whether some of these methods would be better off with their concrete implementations moved into the PathDistribution subclass? (Of course leaving abstract methods behind in Distribution where that makes sense.) This would grant these concrete methods direct access to the stuff they need inside PathDistribution, instead of having to add more interfaces to Distribution for stuff that really only makes sense for PathDistribution.

Still, this is a much bigger refactoring than I set out to do, and I would not feel comfortable starting this without consulting you.

Originally posted by @jherland in https://github.com/python/importlib_metadata/pull/437#discussion_r1141220985

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

まず Distribution クラスと PathDistribution クラス、および issue で名前が挙げられているメソッド at()、metadata()、entry_points()、files()、requires()、read_text()、locate_file() を読んでください。元の背景を確認するため、リンク先の pull request の議論を確認してください。完了とするには、サブクラス固有の動作を分離するための合意済みの設計と、関連する distribution の機能を維持する実装が必要です。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
python
領域
devtools
issue の種類
リファクタリング
難易度
5/5
見積もり時間
1週間以上
活発さ
停滞
明瞭さ
説明が足りない
初心者へのやさしさ
25/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。