컴포저(Composer) 공식 가이드 번역 - 3. 라이브러리

라이브러리(Libraries)

이번 장은 컴포저(Composer)를 통해 어떻게 라이브러리를 설치가능하게 하는지 말해줄 것이다.

모든 프로젝트는 패키지이다(Every project is a package)

디렉토리에  composer.json 가 있는 순간 그 디렉토리는 하나의 패키지이다. 프로젝트에 require를 추가하면 , 이는 다른 패키지에 의존하는 패키지를 만드는 것이다. 패키지와 라이브러리의 유일한 다른 점은 프로젝트는 이름이 없는 패키지라는 것이다. 

패키지를 설치가능하게하려면 이름을 주어야한다.  composer.json에  name프로퍼티를 추가함으로써 그렇게 할 수 있다.

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

프로젝트 네임이  acme/hello-world인 경우acme 이 벤더네임(vendor name)이다. 벤더네임은 의무적이다.

주의: 만일 벤더네임으로 무엇을 사용할 지 모른다면 당신의 GitHub 유저명이 보통 좋은 이름이 된다. 패키지네임이 대소문자를 가리지는 않지만 모두 소문자로 하고 단어의 분리는 대쉬(dashes)로 하는 것이 컨벤션(convention)이다.

플랫폼 패키지(Platform packages)

컴포저는 플랫폼패키지를 갖고있는데 이는 시스템에 설치된 것들을위한 가상패키지(virtual packages)이지 컴포저에 의해 실제로 설치될 수 있는 것이 아니다. 이는 PHP 자체를 포함해서 PHP 익스텐션과 몇몇 시스템 라이브러리를 포함한다.

• php 는 사용자의 PHP 버전을 나타내는데 이는 당신이 제한(constraint)을 둘수 있도록한다. 예: >=5.4.0.  64bit 버전의 PHP를 요구(require)하려면 php-64bit 패키지를 요구할 수 있다..

• hhvm 은 HHVM 런타임의 버전(즉, HipHop Virtual Machine)을 나타낸다. 이는 당신이 제한(constraint)을 둘 수 있도록한다. 예: '>=2.3.3'.

• ext-<name> 은 당신이 PHP 익스텐션(includes core 익스텐션을 포함하여)을 요구할 수 있도록 한다. 버저닝(Versioning)은 여기서 상당히 불규칙하다 따라서 종종 제한(constraint)을  * 로 하는 것이 좋다. 익스텐션 패키지 네임의 한 예:  ext-gd.

• lib-<name> 는 PHP에의해 사용되는 라이브러리의 버전에 제한을 둘수 있게한다. 다음의 것들이 가능하다: curl, iconv, icu, libxml, openssl, pcre, uuid, xsl.

지역적으로(locally) 사용가능한 플랫폼 패키지의 리스트를 얻으려면 show --platform 을 사용한다.

버전명시하기(Specifying the version)

Packagist에 당신의 패키지를 퍼블리싱할때 VCS (git, svn, hg) 정보로부터 버전을 추론할 수 있다. 즉, 명시적으로 이를 선언할 필요는 없다는 것이다.  tags 와 branches 를 읽고 이들로부터 어떻게 버전넘버가 추출되는지 알아보라.

만일 당신이 수작업으로 패키지를 만들고 정말로 명시적으로 선언해야한다면  version필드를 추가할 수 있다:

{
    "version": "1.0.0"
}

주의: 당신은 명시적으로 버전필드를 표시하는것을 피할 수 있다. 왜냐하면 값이 태그네임과 매치되어야하기때문이다(because for tags the value must match the tag name.)

태그(Tags)

버전(version)같은(과 유사한) 모든 태그를위해 그 태그의 패키지버전이 생성될 것이다(For every tag that looks like a version, a package version of that tag will be created.). 이는 -patch (-p), -alpha (-a), -beta (-b) 혹은 -RC의 옵션 접미사(suffix)와 더불어 'X.Y.Z' 혹은  'vX.Y.Z' 와 매치되어야한다. 접미사는 다음에는 숫자가 올 수 있다.

아래는 유효한 태그네임의 예이다:

• 1.0.0
• v1.0.0
• 1.10.5-RC1
• v4.4.4-beta2
• v2.0.0-alpha
• v2.0.4-p1

주의: 당신의 태그가 접두어로(prefixed) v가 있다고해도 require 스테이트먼트(statement)의 버전 제한( version constraint )은 접두어(prefix)없이 명시되어야한다.(예. tag v1.0.0 은  1.0.0로 된다)

브랜치(Branches)

모든 브랜치를 위해 패키지 개발 버전(package development version)이 생성될 것이다.  만일 브랜치네임이 버전과 같다면(비슷하다면)  그 버전은  {branchname}-dev일 것이다. 예를들어, 브랜치 2.0 은  2.0.x-dev 버전을 갖게 될것 이다.(.x 는 기술적 이유로 추가된다, 브랜치롤 확실하게 인식되도록하기위해). 2.0.x 브랜치는 유효하고 또  2.0.x-dev 로 될 수도 있다. 만일 브랜치가 버전과 같지않다면(비슷하지않다면)  dev-{branchname}같을 것이다. master 는 dev-master 버전이 된다.

다음은 버전 브랜치네임(version branch names)의 몇몇 예이다:

• 1.x
• 1.0 (equals 1.0.x)
• 1.1.x

주의: 개발버전(development version)을 설치할때는 그 source. 로부터 자동으로 당겨질 것이다. 좀더 상세한 것은 install 커맨드를 보라

엘리어스(별명,Aliases)

브랜치네임을 버전으로 엘리어스할 수있다. 예를들어,  dev-master 를 1.0.x-dev, 로 엘리어스할 수 있는데 이는 당신이 모든 패키지에서 1.0.x-dev 를 요구할 수 있게한다.

 Aliases 참고하라

Lock file

당신의 라이브러리를 위해서 원한다면  composer.lock 파일을 커밋할 수 있다. 이는 당신의 팀이 항상 동일한 의존성에서 테스트하는데 도움을 준다. 그러나, 이 lock 파일은 거기에 의존하는 다른 프로젝트에는 영향을 주지않는다.  단지 메인 프로젝트에만 영향을 준다.

만일 lock파일을 커밋하기 원치않는다면 그리고 당신이  git를 사용하고 있다면 , .gitignore.에 추가하라.

VCS에 퍼블리싱하기(Publishing to a VCS)

당신이 composer.json 파일을 담고있는  VCS 저장소(repository, 버전코트롤시스템, 예. git))를 갖고있다면 당신의 라이브러리는 이미 컴포저로 실행가능하다. 이번 예에서 우리는  GitHub 의 github.com/username/hello-world에  acme/hello-world 라이브러리를 퍼블리싱할 것이다.

이제 acme/hello-world 패키지를  테스트하기위해, 우리는 새로운 프로젝트를 지역적(locally)으로 만든다.  acme/blog라고 이를 부르자. 이블로그는  monolog/monolog 에 의존하는  acme/hello-world 에 의존할 것이다. 우리는  composer.json가 포함된 어딘가에 새로운blog 디렉토리를 만듬으로써 이를 수행할 수 있다.

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

이경우에 네임은 필요치않다. 왜냐하면 우리는 블로그를 라이브러리로 퍼블리싱하기를 원치않기때문이다. 여기선 어떤 composer.json 이 표시되었는지를 확인하기위해 추가된다.

이제 우리는 블로그 앱(blog app)에  어디에서 hello-world 의존성을 찾는지를 말할 필요가있다. 우리는  블로그의 composer.json에 패키지 저장소 스펙(package repository specification)을 추가함으로써 이를 수행한다.

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

어떻게 패키지 저장소가 작동하고 어떤 다른 타입이 있는지는 Repositories.를 참고하라

이게 전부다. 이제 당신은 컴포저의 install 커맨드를 실행함으로서 의존성을 설치할 수 있다.!

리캡(Recap):  composer.json 를 포함하는 어떠한  git/svn/hg 저장소도 패키지 저장소를 명시함으로써 당신의 프로젝트에 추가될 수 있고 require 필드에서 의존성을 선언할 수 있다.

Pachagist에 퍼블리싱하기(Publishing to packagist)

이제, 당신은 패키지를 퍼블리싱 할 수 있다. 그러나 매번  VCS 저장소를 명시하는것은 번잡한 일이다.   당신은 당신의 모든 사용자가 그러기를 강요할 수는 없다.

당신이 인식할 수 있는 또 다른 것은 우리가 monolog/monolog 를위해  패키지 저장소를 명시하지 않았다는 것이다. 

어떻게  돌아갔지? 답은 Packagist이다.

Packagist 는 컴포저의 메인 패키지 저장소이고 디폴트로 활성화되어있다.  Packagist 에 퍼블리싱 된 모든 것은 자동으로  컴포저를 통해 사용가능해진다. 왜냐하면  Monolog가 Packagist에 존재하기에( Monolog is on Packagist, ) 우리는 다른 추가적인 저장소를 명시함이 없이 그것에 의존할 수 있기때문이다.

만일 hello-world 를 다함께 공유하기를 원한다면  이를  Packagist 에 퍼블리싱할수 있다. 정말 쉽다.

단지 Packagist 를 방문해서 "Submit"를 클릭하면 된다. 만일 아직 회원가입을하지 않았다면 회원가입을 해야하고 그런후 URL 을 당신의 VCS 저장소 즉, Packagist가 크롤링하기 시작하는지점, 로 submit 할 수 있다. 이렇게 해서 다되었으면 이제 당신의 패키지는 모든사람이 사용할 수 있다!

원문 : https://getcomposer.org/doc/02-libraries.md