— y2sunlight 2020-07-16

Packagist に戻る

ここでは Packagist にパッケージを登録する前に知っておきたい基礎知識を説明します。本章は、Packagist サイトの https://packagist.org/about の「How to submit packages?」を翻訳し補足したものです。

関連記事

• Packagist アカウントの作成
• Packagist パッケージ登録の基礎知識
• 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 にすでに存在するベンダー名のパッケージを許可なしに公開することはできません。既存のベンダー名のパッケージを公開できるようにするには、そのベンダー内の少なくとも一つのパッケージの保守担当者である必要があります。

The composer.json file should reside at the top of your package's git/svn/.. repository, and is the way you describe your package to both packagist and composer.

A typical composer.json file looks like this:

{
    "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"
        }
    }
}

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 library. If 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 installer. In the absence of custom type, you can omit it or use “library”.

Once you have this file committed in your repository root, you can submit the package to Packagist by entering the public repository URL.