[번역] 의존성 관리 도구 컴포저 - 라이브러리 ~ pamooochim

* url: https://getcomposer.org/doc/02-libraries.md

라이브러리

이번 장은 컴포저를 통해서 설치할 수 있는 라이브러리를 만드는지 이야기할 것이다.

모든 프로젝트는 패키지이다

디렉토리에서 composer.json파일을 만드는 즉시 그 디렉토리는 패키지가 된다. 여러분은 require를 프로젝트에 추가할 때 다른 패키지에 의존하는 패키지를 만드는 셈이다. 여러분의 프로젝트와 라이브러리의 차이점은 여러분의 프로젝트가 이름 없는 패키지라는 점이다.

그 패키지를 설치 가능하도록 하기 위해서 이름을 지정해야한다. composer.json 파일에서 name 속성을 추가한다.

{
    "name": "acme/hello-world",
    "require": {
        "monolog/monolog": "1.0.*"
    }
}

프로젝트 이름이 acme/hello-world인 경우에 acme 부분은 벤더 이름이다. 벤더 이름을 제공하는 것은 필수이다.

참고: 만약 여러분이 벤더 이름을 어떤 것으로 사용 할 지 모르겠다면 보통 GitHub 사용자 이름이 괜찮다. 패키지 이름은 대소문자를 구별하고 있지만 모두 소문자로 하고 단어 구분은 하이픈으로 사용하는 것을 규칙으로 하고 있다.

플랫폼 패키지

컴포저에는 플랫폼 패키지가 있는데 시스템에 설치되어 있는 가상 패키지이지만 실제로는 컴포저가 설치한 것이 아니다. 이는 PHP 자체, PHP 확장 기능, 몇몇 시스템 라이브러리를 포함하고 있다.

php는 제약 조건을 적용할 수 있도록 사용자 PHP 버전을 나타낸다. 예: >=5.4.0. PHP에 64비트 버전을 요청하기 위해 여러분은 php-64bit 패키지를 요청할 수 있다.
hhvm는 HHVM 실행 시간 (아카 힙홉 가상 머신) 버전을 나타내고 제약 조건을 적용할 수 있다. 예: '>=2.3.3'.
ext-<name>은 PHP 확장 기능 (코어 확장을 포함) 을 요구할 수 있다. 버전 지정은 여기에 아주 일치하지 않을 수도 있기에 보통 별표 (*) 로 제약 조건을 설정하는 것이 좋다. 확장 패키지 이름 예시는 ext-gd이다.
lib-<name>은 PHP가 사용하는 라이브러리 버전을 만들도록 제약 조건을 걸 수 있다. 다음은 <name> 부분에 사용할 수 있는 내용이다 : curl, iconv, icu, libxml, openssl, pcre, uuid, xsl.

로컬에서 사용할 수 있는 플랫폼 패키지 리스트를 보려면 show --platform을 사용하면 된다.

버전 지정하기

패키지스트에서 여러분의 패키지를 발행할 때 VCS (git, svn, hg) 정보에서 버전을 유추할 수 있다. 이는 여러분이 명시적으로 선언할 필요가 없다는 것을 의미한다. 버전 숫자가 어떻게 추출되는지 태그와 브랜치를 읽어보자.

수동으로 패키지를 만들어서 거나 명시적으로 지정해야 하는 경우 여러분은 그저 version 항목을 추가하면 된다.

{
    "version": "1.0.0"
}

참고: 여러분은 되도록이면 명시적으로 버전 항목을 지정하지 않도록 해야한다. 왜냐하면 태그 값은 태그 이름과 일치해야 하기 때문이다.

브랜치

모든 브랜치의 경우 패키지 개발 버전이 생성된다. 브랜치 이름이 버전 이름과 같으면 버전은 {branchname}-dev가 될 것이다. 예를 들어 브랜치 2.0은 2.0.x-dev 버전을 얻는다 (.x는 브랜치로 인식하기 위해 기술적인 이유로 추가됨). 또한 2.0.x 브랜치는 유효할 뿐 아니라 2.0.x-dev로 전환된다. 만약 브랜치가 버전과 같지 않으면 dev-{branchname}가 될 것이다. master는 dev-master 버전이 된다.

다음은 버전 브랜치 이름에 관련된 예시이다.

1.x
1.0 (1.0.x와 같음)
1.1.x

참고: 여러분이 개발 버전을 설치하면 그 source에서 자동으로 가져올 것이다. 더 자세한 내용은 install를 참고하라.

별칭

버전에 브랜치 별칭을 지정할 수 있다. 예를 들어 여러분은 dev-master를 1.0.x-dev로 지정하고 모든 패키지에서 1.0.x-dev를 요구할 수 있다.

더 자세한 내용은 별칭을 참고하라.

잠금 파일

라이브러리의 경우에 여러분이 원하면 composer.lock 파일을 커밋할 수 있다. 이는 여러분의 팀이 동일한 의존성 버전으로 테스트할 수 있도록 도와준다. 그러나 이 잠금 파일은 그것에 의존하는 다른 프로젝트에 어떤 영향도 주지 않을 것이다. 메인 프로젝트에만 영향을 줄 뿐이다.

만약 여러분이 잠금파일을 원하지 않으면서 git을 사용하고 있다면 .gitignore에 추가하라.

VCS로 발행하기

만약 composer.json 파일을 포함하는 VCS 저장소 (버전 관리 시스템, 예: git) 가 있으면 여러분의 라이브러리는 이미 컴포저가 설치할 수 있는 상태이다. 이 경우에 우리는 github.com/username/hello-world 밑에서 GitHub에 acme/hello-world 라이브러리를 발행할 것이다.

이제 acme/hello-world 패키지를 설치 테스트하기 위해서 로컬에 새 프로젝트를 생성한다. 우리는 acme/blog를 호출할 것이다. 이 블로그는 acme/hello-world에 의존하고 또 그것은 monolog/monolog에 의존하고 있을 것이다. 우리는 어딘가에 새 blog 디렉토리를 생성하고 composer.json를 포함하여 수행할 수 있다.

{
    "name": "acme/blog",
    "require": {
        "acme/hello-world": "dev-master"
    }
}

우리는 라이브러리로 이 블로그를 발행하고 싶지 않기 때문에 이 경우에 이름은 반드시 필요하지 않는다. 이름은 composer.json에 기술되는 것을 명확히 하기 위해 추가하였다.

이제 우리는 블로그 앱이 hello-world 의존성을 찾도록 설정해야한다. 우리는 블로그의 composer.json 패키지에 저장소 사양을 추가하여 이 작업을 수행할 수 있다.

{
    "name": "acme/blog",
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/username/hello-world"
        }
    ],
    "require": {
        "acme/hello-world": "dev-master"
    }
}

패키지 저장소가 동작하는 것과 사용할 수 있는 다른 종류에 대해서 더 자세히 알고 싶다면
저장소를 참고하라.

그게 다이다. 여러분은 이제 컴포저 install 명령어를 실행하여 의존성을 설치할 수 있다!

요약: composer.json 를 포함하는 모든 git/svn/hg 저장소는 캐피지 저장소를 지정하고 require 항목에서 의존성을 정의하는 것으로 여러분의 프로젝트에 추가할 수 있다.

패키지스트 발행하기

자, 이제 여러분은 패키지를 발행할 수 있다. 그러나 매번 VCS 저장소를 지정하 것은 번거롭다. 여러분은 모든 사용자가 그렇게 하도록 강요하면 안된다.

여러분이 눈치챈 다른 것은 monolog/monolg를 위한 패키지 저장소를 지정하지 않았다는 것이다. 어떻게 동작하는 것일까? 대답은 패키지스트이다.

패키지스트는 컴포저를 위한 매인 패키지 저장소이고 기본적으로 활성화되어 있다. 패키지스트에서 발행된 모든 것은 컴포저를 통해서 자동으로 사용 가능하다. 모놀로그는 패키지스트에 있기 때문에 우리는 저장소를 추가로 지정하지 않고도 의존할 수 있다.

만약 전세계에 hello-world를 공유하고 싶다면 물론 패키지스트에 발행하면 된다. 이렇게 하면 정말 간단하다.

여러분은 간단히 패키지스트에 방문하고 "Submit"을 누른다. 가입되어 있지 않다면 가입하라는 메세지가 뜰 것이고 패키지스트가 크롤링을 시작하는 지점에서 여러분의 VCS 저장소에서 URL을 전송할 수 있도록 한다. 완료되면 여러분의 패키지는 누구나 사용 할 수 있다!

pamooochim

2015-07-16