Packagist で Composer package を公開する手順メモ

はじめに

Packagist に Composer package を登録したいと思い立ち試した。 その個人的なメモ。
参考にする人もいないとおもうが、設定内容をよく理解していないでやっているので、ご了承ください。

前提事項

  • PHPページをホストできる環境がある
  • composer がインストールされている
  • git がインストールされている
  • Packagist にアカウントがある
  • GitHub にアカウントがある

やりたいこと

ライブラリのプロジェクトを作り、Packagist に登録する。
ウェブアプリケーションのプロジェクトを作り、登録したライブラリを利用する。

手順概要

ライブラリのプロジェクトを作る

~/git$ # プロジェクトディレクトリを作り、移動

~/git$ mkdir hello-lib
~/git$ cd hello-lib/

~/git/hello-lib$ # `composer.json`を作る

~/git/hello-lib$ composer init


  Welcome to the Composer config generator



This command will guide you through creating your composer.json config.

Package name (<vendor>/<name>) [mitsuaki/hello-lib]: quwahara/hello-lib
Description []: Tutorial for a composer library
Author [, n to skip]: mitsuaki kuwahara <quwahara@gmail.com>
Minimum Stability []: dev
Package Type (e.g. library, project, metapackage, composer-plugin) []: library
License []: MIT

Define your dependencies.

Would you like to define your dependencies (require) interactively [yes]? no
Would you like to define your dev dependencies (require-dev) interactively [yes]? no

{
    "name": "quwahara/hello-lib",
    "description": "Tutorial for a composer library",
    "type": "library",
    "license": "MIT",
    "authors": [
        {
            "name": "mitsuaki kuwahara",
            "email": "quwahara@gmail.com"
        }
    ],
    "minimum-stability": "dev",
    "require": {}
}

Do you confirm generation [yes]? yes

ライブラリになる簡単なクラスを作る

hello-lib/src/Hello.php

<?php

namespace quwahara\HelloLib;

class Hello
{
    public function helloTo($subject)
    {
        return "Hello, {$subject}";
    }
}

ライブラリのプロジェクトをGitHubに登録する

GitHub へ以下のリポジトリを作る

https://github.com/quwahara/hello-lib

プロジェクトを push する

~/git/hello-lib$ git init .
~/git/hello-lib$ git add .
~/git/hello-lib$ git remote add origin https://github.com/quwahara/hello-lib.git
~/git/hello-lib$ git push -u origin master

GitHubリポジトリをPackagist に登録する

Packagist にアカウントを作り、ログインする。
Packagist ページ右上の Submit を押す。
Repository URL に GitHubリポジトリURLを入力する。
Checkを押す。

f:id:quwahara:20190919004505p:plain
Repository URL に GitHubリポジトリURLを入力

Checkがうまくいくと、Submitが押せるようになるので押す。

f:id:quwahara:20190919004706p:plain
Checkがうまくいくと、Submitが押せるようになるので押す

Submitがうまくいくと、下のようになる。

f:id:quwahara:20190919004734p:plain
Submitがうまくいくと、下のようになる

Packagist と GitHub を連携させる WebHook というのがある。
GitHub リポジトリが更新されると、Packagist にもそれが伝わる仕組みのようだ。
その設定方法は失念した。
上の画面の Update を押すと、WebHook の設定になった気がした。

Packagist 登録は以上です。

ウェブアプリケーションのプロジェクトを作る

~/git$ mkdir hello-app
~/git$ cd hello-app/
~/git/hello-app$ composer init


  Welcome to the Composer config generator



This command will guide you through creating your composer.json config.

Package name (<vendor>/<name>) [mitsuaki/hello-app]: quwahara/hello-app
Description []: Tutorial for composer library
Author [Mitsuaki Kuwahara <quwahara@gmail.com>, n to skip]:
Minimum Stability []: dev
Package Type (e.g. library, project, metapackage, composer-plugin) []: project
License []: MIT

Define your dependencies.

Would you like to define your dependencies (require) interactively [yes]? no
Would you like to define your dev dependencies (require-dev) interactively [yes]? no

{
    "name": "quwahara/hello-app",
    "description": "Tutorial for composer library",
    "type": "project",
    "license": "MIT",
    "authors": [
        {
            "name": "Mitsuaki Kuwahara",
            "email": "quwahara@gmail.com"
        }
    ],
    "minimum-stability": "dev",
    "require": {}
}

Do you confirm generation [yes]? yes


~/git/hello-app$ # 登録したライブラリを require する

~/git/hello-app$ composer require quwahara/hello-lib
Using version dev-master for quwahara/hello-lib
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
  - Installing quwahara/hello-lib (dev-master b1ab0e1): Cloning b1ab0e1dfb from cache
Writing lock file
Generating autoload files

ライブラリを利用する簡単なアプリケーションを作る

hello-app/public/index.php

<?php

require_once __DIR__ . '/../vendor/autoload.php';

use quwahara\HelloLib\Hello;

$hello = new Hello();

echo $hello->helloTo("world");

必要ではないが GitHub へも登録した

https://github.com/quwahara/hello-app

ウェブアプリケーションをホストする

~/git/ 以下が http://localhost/ でアクセスできる前提で下を開く。

http://localhost/hello-app/public/index.php

Hello, world が表示される。

f:id:quwahara:20190919012313p:plain
Hello, world表示

趣味で作る Web Application Framework の指針

趣味で Web Application Framework を作りたいと考えている
ちんたら作るに当たって、いつでも初心に戻れるよう、指針を記録したい
思いついたら追記する

  • 機能の実装がどうなっているか推測がつきやすい [2019-09-08]
  • 追加したい機能から、実装方法が引ける文書がある [2019-09-08]
  • とりあえず動かせるようになっている [2019-09-08]
  • アプリケーションが自己説明的になっている [2019-09-08]
  • ユーザーアカウント管理機能がある [2019-09-08]

Web Application FrameworkにBTS機能があればいいのになと妄想している話

TLDR

  • 小チーム体制で開発をしている
  • 決定の経緯が後から参照できなくなり問題
  • BTSを運用したいが難しい
  • Web Application FrameworkがBTS機能があればいいのに

Web Application開発でよく感じる問題点

Web Application開発を進めているときによく感じる問題点がある。

問題点の前提になるので開発の体制など背景を先に述べておこう。 開発チームの人数は10人前後の小さなチームを念頭に置いている。 開発体制は案件の主幹の会社があり、その下に協力会社がいる。

このような体制で進める開発プロジェクトでよく感じる問題点、 それは何かの決定の過程が記録に残らないことだ。

何かの決定について例をあげる。

  • 最も端的なところでは Web Application の仕様
  • 仕様に盛り込まないと決めたこと
  • アプリケーション動作としては問題だが、現実的な判断から放置することにした

などなどである。 例をあげれば、そういうことならプロジェクトの中で他にもこんな決定をしたことがあると、 思い浮かぶことが多々あるだろう。 そのような決定を下したときに、いろいろな形で議論があったはずだ。 それは1人でいろいろ思案した結果かも知れないし、 数人だったりチーム全員で議論した結果かも知れない。 議論ではなく、外的要因から自ずとその選択をすることもあるだろう。

問題点はその決定に至った背景が記録に残らないことだ。 もしくは記録はExcelやWordで議事録を残しているということもあるだろう。 それについて問題視したいのは検索性が低いことだ。 確かに Explorer を使えばファイル内まで検索できるが、 検索対象に含めるファイルがバラバラに置かれたり、 日にちが経つことで移動されたりなど問題が多い。 多くの人の感覚では何かの決定の経緯を調べるときに、 Explorer でファイルの内容を検索しようという風には連想しないかも知れない。

背景の記録がない、あるいは探し出すのが難しいと問題が起こる。

  • 背景を理解していないと、やるべき試験が行えない。
  • 本来やるべきでないと結論に至った作業を行ってしまい、 そう言えばやらなくていい作業だったと、以前に行った議論を繰り返してしまう。 無駄な作業の繰り返しが起こる。
  • 積み残していた課題を喪失してしまう。
  • 新たに加わったメンバーが経緯を知る由がない。

などなど。 自分が置かれている環境がその様な場合が多いだけの印象だろうが、 このような問題は小さいチームの開発でよく起きるのではないだろうか。

王道の回避策 は難しい

この問題を回避する方法の王道は、WikiBTS(Bug tracking system)を使うことだろう。 だがWikiBTSなしで進めている開発案件はまだまだ多いのではないだろうか。 それらを運用するとなると、案件の主幹の会社がもつことになるとおもうが、 主幹の会社で導入するのはかなり難しいだろう。 難しいと考える理由だ。

  • WikiBTSの有用性を理解している層が少ない、認知度が低い。
  • WikiBTSの構築を誰がするのか、運用を誰が行っていくか。
  • 導入先サーバーはどう手配するのか。
  • 実行環境の構築が必要になる。ウェブサーバーを導入し、スクリプト言語の実行環境、それにまつわるパッケージなどの導入がいる
  • データベース(以降、DB)も構築、運用しなければならない。
  • 導入できたとして、主幹会社でない人間のアクセスをどうするのか。

自ずと共有ディレクトリでルールを決めて、既定の書式でファイルを置きましょうとなる。

Web Application FrameworkにBTS機能があればいいのに

そんな困難を乗り越える解決策として妄想するのが、 開発で採用するWeb Application Frameworkに、 Out-of-the-boxで使えるBTS機能が組み込まれていることだ。 もしくは各プログラミング言語のパッケージマネージャーだけで、 開発している製品で利用するライブラリかのように導入できるBTS機能だ。 Frameworkの一部だったり、利用するライブラリかのようであれば、 BTSそのものを導入するための許可の難易度が下がるだろう。 導入先のサーバーだが、さすがに開発案件を進めているのであれば、 開発用のサーバーあるはずだ。 開発しているプロダクトの一部なのだから、 当然、開発しているサーバーにのせることになる。 実行環境も開発しているプロダクトを動かすわけだから、そこにあるはずだ。 データベースもしかりである。

そんなわけで、Web Application FrameworkにBTS機能があればいいのになと妄想している。

とある Java製のWeb Application Framework をさわった

事前に覚えておかなければ多いと感じた

英字大文字2文字、3文字の専門用語があり、それぞれが何の略で、何の役割を追うのか、はじめの方によむ資料にでは見つけられなかった

その専門用語を目にするたびにソースを追っていたもやもやした

ドキュメントは豊富に用意されていた

デバッグモードは画面に豊富な情報が出ていてよかった

インクリメンタルに作りながら、学習するのは難しいように思えた

ワーキング・ホリデーを読んだ

坂木司先生、ホリデーシリーズの1冊め

元ヤン、元ホストの配達員ヤマトと突然あらわれた息子、進とのひと夏の物語

よく出来た息子、進との交流で、ヤマトが徐々に父性に目覚めていく

安心して下さい、トリックも殺人もサイコパスもありません

軽い気持ちで少しほっこりしたい気分のときにおすすめ