メインメニュー
XAMPP アレンジ
IED
WSL2
-
道具箱
リポジトリ編
フレームワーク編
公開ソフトウェア
メタ
リンク
- PHP ライブラリ
- PHP 言語
packagist:knowledge文書の過去の版を表示しています。
編集中Packagist パッケージ登録の基礎知識
— y2sunlight 2020-07-16
ここでは Packagist にパッケージを登録する前に知っておきたい基礎知識を説明します。本章は、Packagist サイトの https://packagist.org/about の「How to submit packages?」を翻訳し補足したものです。
関連記事
- Packagist パッケージ登録の基礎知識
リンク
- https://packagist.org/ — Packagistの本家
- https://packagist.org/about — Packagistについて(設定方法の情報が掲載されている)
パッケージのネーミング
( packagist でパッケージを提出するには ) まず第一に、パッケージ名を選択する必要があります。これは変更できないので非常に重要なステップであり、将来的に競合を回避するために十分に一意である必要があります。
パッケージ名は、スラッシュ(
/
) で結合された ベンダー名 と プロジェクト名 で構成されます。ベンダー名は、名前の競合を防ぐために存在します。たとえば、ベンダー名を含めることにより、igorw
とseldaek
の両方に、パッケージにigorw/json
とseldaek/json
という名前を付けて、json
という名前のライブラリーを作成できます。場合によっては、ベンダー名とパッケージ名が同じになることがあります。この例は、
monolog/monolog
です。一意の名前を持つプロジェクトの場合、これが推奨されます。また、後で同じベンダーに関連プロジェクトを追加することもできます。ライブラリを保守している場合、これにより、ライブラリを小さく切り離したパーツに分割することが本当に簡単になります。参考の為に、典型的なパッケージ名のリストを次に示します:
// Monolog はライブラリで、ベンダー名とパッケージ名が同じです。 monolog/monolog // これはdrupalモジュールの名前のようです(monolog によって保守/提供されてます。 // drupalチームがそれを行っているとしたら、ベンダーはdrupalになります)。 monolog/monolog-drupal-module // Acme は会社または人です。ここではパッケージに一般的な名前(Email)で名前を付けることができます。 // 独自のベンダー名前空間にある限り、他の誰とも競合しません。 acme/email
packagist のベンダー名は、ひとたび、その名前でパッケージが公開されると保護されます。つまり、packagist にすでに存在するベンダー名のパッケージを許可なしに公開することはできません。既存のベンダー名のパッケージを公開できるようにするには、そのベンダー内の少なくとも一つのパッケージの保守担当者である必要があります。
パッケージのバージョン管理
パッケージの新しいバージョンは、バージョン管理システムのリポジトリに作成したタグから自動的にフェッチされます。
バージョニングを管理する最も簡単な方法は、composer.json ファイルからバージョンフィールド(
version
)を省略することです。 その後は、バージョン番号はタグとブランチ名から解析されます。タグ/バージョン名は
X.Y.Z
またはvX.Y.Z
と一致する必要があり、RC, beta, alpha または patch バージョンのオプションのサフィックスが付いています。次に、有効なタグ名の例をいくつか示します:1.0.0 v1.0.0 1.10.5-RC1 v4.4.4beta2 v2.0.0-alpha v2.0.4-p1
ブランチは自動的に “dev” バージョンとして表示され、ライブラリの最新かつ最高のものを試してみたい人なら誰でも簡単にインストールできますが、リリースにタグを付けてはいけないという意味ではありません。セマンティックバージョニングの使用を強くお勧めします。
例えば、dev-master
は masterブランチの最新バージョンを表します。
composer.jsonの作成
composer.json ファイルは、パッケージの git/svn/などの リポジトリの先頭に配置する必要があり、packagist と composer の両方にパッケージについて説明する手段となります。
典型的な composer.json ファイルは次のようになります。
{ "name": "monolog/monolog", "type": "library", "description": "Logging for PHP 5.3", "keywords": ["log","logging"], "homepage": "https://github.com/Seldaek/monolog", "license": "MIT", "authors": [ { "name": "Jordi Boggiano", "email": "j.boggiano@seld.be", "homepage": "http://seld.be", "role": "Developer" } ], "require": { "php": ">=5.3.0" }, "autoload": { "psr-0": { "Monolog": "src" } } }
この情報のほとんどは明白で、キーワード(
keywords
)はタグであり、パッケージが持つ依存関係のリスト(require
)が必要です。もちろん、これはphpバージョンだけでなく、パッケージでもかまいません。ext-foo
を使用して、php拡張モジュールを要求できます(例:ext-cur
l)。ほとんどの拡張モジュールはバージョン情報を公開しない点に注意して下さい。従って、確実に公開していない限り、“ext-curl”:“*”
を使用して、どのバージョンでも許可する方が安全です。最後に、タイプフィールド(type
)ですが、上記の場合は、これがライブラリであることを示しています。フレームワークなどに対するプラグインを作成し、それらが composer を統合している場合、独自のインストーラーを使用してパッケージをインストールするために使用できるプラグイン用のカスタムパッケージタイプがある場合があります。カスタムタイプがない場合は、それを省略するか、“ライブラリ” を使用できます。このファイルをリポジトリのルートでコミットしたら、パブリックリポジトリのURLを入力してパッケージを Packagist に送信 できます。
スケジュールの更新
New packages will be crawled immediately after submission if you have JS enabled.
Existing packages without auto-updating (GitHub/BitBucket hook) will be crawled once a week for updates. When a hook is enabled packages are crawled whenever you push, or at least once a month in case the crawl failed. You can also trigger a manual update on your package page if you are logged-in as a maintainer.
It is highly recommended to set up the GitHub/BitBucket service hook for all your packages. This reduces the load on our side, and ensures your package is updated almost instantly. Check the how-to below.
The search index is updated every five minutes. It will index (or reindex) any package that has been crawled since the last time the search indexer ran.
packagist/knowledge.1594967423.txt.gz · 最終更新: 2020/07/17 15:30 by y2sunlight
コメント