Ground Sunlight

Windowsで作る - PHPプログラミングの開発環境

ユーザ用ツール

サイト用ツール


packagist:knowledge

差分

このページの2つのバージョン間の差分を表示します。

この比較画面にリンクする

両方とも前のリビジョン 前のリビジョン
次のリビジョン
前のリビジョン
packagist:knowledge [2020/07/17 11:46]
y2sunlight [パッケージのネーミング]
packagist:knowledge [2020/07/17 16:14] (現在)
y2sunlight [更新スケジュール]
行 1: 行 1:
-> 編集中 
- 
 ====== Packagist パッケージ登録の基礎知識 ====== ====== Packagist パッケージ登録の基礎知識 ======
  --- //[[http://www.y2sunlight.com|y2sunlight]] 2020-07-16//  --- //[[http://www.y2sunlight.com|y2sunlight]] 2020-07-16//
行 23: 行 21:
 ===== パッケージのネーミング ===== ===== パッケージのネーミング =====
  
-( packagist でパッケージを提出すには ) まず第一に、パッケージ名を選択する必要があります。これは変更できないので非常に重要なステップであり、将来的に競合を回避するために十分に一意である必要があります。+( packagist でパッケージを提出すには ) まず第一に、パッケージ名を選択する必要があります。これは変更できないので非常に重要なステップであり、将来的に競合を回避するために十分に一意である必要があります。
  
 パッケージ名は、スラッシュ( ''/'' ) で結合された ベンダー名 と プロジェクト名 で構成されます。ベンダー名は、名前の競合を防ぐために存在します。たとえば、ベンダー名を含めることにより、''igorw'' と ''seldaek'' の両方に、パッケージに ''igorw/json'' と ''seldaek/json'' という名前を付けて、''json'' という名前のライブラリーを作成できます。 パッケージ名は、スラッシュ( ''/'' ) で結合された ベンダー名 と プロジェクト名 で構成されます。ベンダー名は、名前の競合を防ぐために存在します。たとえば、ベンダー名を含めることにより、''igorw'' と ''seldaek'' の両方に、パッケージに ''igorw/json'' と ''seldaek/json'' という名前を付けて、''json'' という名前のライブラリーを作成できます。
行 29: 行 27:
 場合によっては、ベンダー名とパッケージ名が同じになることがあります。この例は、''monolog/monolog'' です。一意の名前を持つプロジェクトの場合、これが推奨されます。また、後で同じベンダーに関連プロジェクトを追加することもできます。ライブラリを保守している場合、これにより、ライブラリを小さく切り離したパーツに分割することが本当に簡単になります。 場合によっては、ベンダー名とパッケージ名が同じになることがあります。この例は、''monolog/monolog'' です。一意の名前を持つプロジェクトの場合、これが推奨されます。また、後で同じベンダーに関連プロジェクトを追加することもできます。ライブラリを保守している場合、これにより、ライブラリを小さく切り離したパーツに分割することが本当に簡単になります。
  
-の為に、典型的なパッケージ名のリストを次に示します:+の為に、典型的なパッケージ名のリストを次に示します:
  
 <code> <code>
行 38: 行 36:
 // drupalチームがそれを行っているとしたら、ベンダーはdrupalになります)。 // drupalチームがそれを行っているとしたら、ベンダーはdrupalになります)。
 monolog/monolog-drupal-module monolog/monolog-drupal-module
- 
-// Acme is a company or person here, they can name their package with a common name (Email). 
-// As long as it's in their own vendor namespace it does not conflict with anyone else. 
  
 // Acme は会社または人です。ここではパッケージに一般的な名前(Email)で名前を付けることができます。 // Acme は会社または人です。ここではパッケージに一般的な名前(Email)で名前を付けることができます。
行 50: 行 45:
  
 \\ \\
 +
 +===== パッケージのバージョン管理 =====
 +
 +パッケージの新しいバージョンは、バージョン管理システムのリポジトリに作成したタグから自動的にフェッチされます。
 +
 +バージョニングを管理する最も簡単な方法は、composer.json ファイルからバージョンフィールド( ''version'' )を省略することです。 その後は、バージョン番号はタグとブランチ名から解析されます。
 +
 +タグ/バージョン名は ''X.Y.Z'' または ''vX.Y.Z'' と一致する必要があり、RC, beta, alpha または patch バージョンのオプションのサフィックスが付いています。次に、有効なタグ名の例をいくつか示します:
 +
 +<code>
 +1.0.0
 +v1.0.0
 +1.10.5-RC1
 +v4.4.4beta2
 +v2.0.0-alpha
 +v2.0.4-p1
 +</code>
 +
 +ブランチは自動的に "dev" バージョンとして表示され、ライブラリの最新かつ最高のものを試してみたい人なら誰でも簡単にインストールできますが、リリースにタグを付けてはいけないという意味ではありません。[[https://semver.org/lang/ja/|セマンティックバージョニング]]の使用を強くお勧めします。
 +
 +> 例えば、''dev-master'' は masterブランチの最新バージョンを表します。
 +
 +\\
 +
  
 ===== composer.jsonの作成 ===== ===== composer.jsonの作成 =====
  
-The composer.json file should reside at the top of your package'git/svn/.. repository, and is the way you describe your package to both packagist and composer.+composer.json ファイルは、パッケージの git/svn/などの リポジトリの先頭に配置する必要があり、packagist と composer の両方にパッケージについて説明する手段となります。
  
-A typical composer.json file looks like this:+典型的な composer.json ファイルは次のようになります。
  
 <code json> <code json>
行 84: 行 103:
 </code> </code>
  
-Most of this information is obvious, keywords are tags, require are list of dependencies that your package has. This can of course be packages, not only a php version. You can use ext-foo to require php extensions (e.g. ext-curl). Note that most extensions don't expose version information, so unless you know for sure it does, it's safer to use "ext-curl": "*" to allow any version of it. Finally the type field is in this case indicating that this is a libraryIf you do plugins for frameworks etc, and if they integrate composer, they may have a custom package type for their plugins that you can use to install the package with their own installerIn the absence of custom type, you can omit it or use "library".+この情報のほとんどは明白で、キーワード( ''keywords'' )はタグであり、パッケージが持つ依存関係のリスト( ''require'' )が必要です。もちろん、これはphpバージョンだけでなく、パッケージでもかまいません。''ext-foo'' を使用して、php拡張モジュールを要求できます(例:''ext-cur''l)。ほとんどの拡張モジュールはバージョン情報を公開しない点に注意して下さい。従って、確実に公開していない限り、''"ext-curl":"*"'' を使用して、どのバージョンでも許可する方が安全です。最後に、タイプフィールド( ''type'' )ですが、上記の場合は、これがライブラリであることを示しています。フレームワークなどに対するプラグインを作成し、それらが composer を統合している場合、独自のインストーラーを使用してパッケージをインストールするために使用できるプラグイン用のカスタムパッケージタイプがある場合があります。カスタムタイプがない場合は、それを省略するか、"ライブラリ" を使用できます。 
 + 
 +このファイルをリポジトリのルートでコミットしたら、パブリックリポジトリのURLを入力してパッケージを Packagist に[[https://packagist.org/packages/submit|送信]] できます。 
 + 
 +\\ 
 + 
 +===== 更新スケジュール ===== 
 + 
 +New packages will be crawled immediately after submission if you have JS enabled. 
 + 
 +JSを有効にしている場合、新しいパッケージは、送信後、即座にクロールされます。 
 + 
 +自動更新(GitHub / BitBucketフック)のない既存のパッケージは、更新のために週に1回クロールされます。フックを有効にすると、プッシュするたびに、パッケージがクロールされ、また、クロールが失敗した場合は少なくとも月に1回はクロールされます。保守担当者としてログインしている場合は、パッケージ画面で手動更新をトリガーすることもできます。 
 + 
 +すべてのパッケージに GitHubまたはBitBucketのサービスフックを設定することを強くお勧めします。これにより、負荷が軽減され、パッケージがほぼ瞬時に更新されます。以下のハウツーを確認してください。 
 + 
 +  * https://packagist.org/about 内の "How to update packages?の項を参照して下さい。 
 + 
 +<div indent><div indent> 
 +GitHubの場合は、本編の「Packagist アカウントの作成」内の「[[packagist:register#githubパッケージの更新方法]]」に "How to update packages?" の翻訳が記載されています。 
 +</div></div>
  
-Once you have this file committed in your repository root, you can [[https://packagist.org/packages/submit|submit the package]] to Packagist by entering the public repository URL.+検索インデックスは5分ごとに更新されます。検索インデクサーが最後に実行されてからクロールされたパッケージがインデックス(または再インデックス)されます。(※即ち、クロールされて(自動更新の場合はプッシュとほぼ同時刻)から最大で5分以内の再インデックスされるという事)
  
 \\ \\
  
  
packagist/knowledge.1594953972.txt.gz · 最終更新: 2020/07/17 11:46 by y2sunlight