* url: https://getcomposer.org/doc/02-libraries.md
그 패키지를 설치 가능하도록 하기 위해서 이름을 지정해야한다.
수동으로 패키지를 만들어서 거나 명시적으로 지정해야 하는 경우 여러분은 그저
다음은 유효한 태그 이름의 예제들이다.
다음은 버전 브랜치 이름에 관련된 예시이다.
더 자세한 내용은 별칭을 참고하라.
만약 여러분이 잠금파일을 원하지 않으면서 git을 사용하고 있다면
이제
이제 우리는 블로그 앱이
저장소를 참고하라.
그게 다이다. 여러분은 이제 컴포저
요약:
여러분이 눈치챈 다른 것은
패키지스트는 컴포저를 위한 매인 패키지 저장소이고 기본적으로 활성화되어 있다. 패키지스트에서 발행된 모든 것은 컴포저를 통해서 자동으로 사용 가능하다. 모놀로그는 패키지스트에 있기 때문에 우리는 저장소를 추가로 지정하지 않고도 의존할 수 있다.
만약 전세계에
여러분은 간단히 패키지스트에 방문하고 "Submit"을 누른다. 가입되어 있지 않다면 가입하라는 메세지가 뜰 것이고 패키지스트가 크롤링을 시작하는 지점에서 여러분의 VCS 저장소에서 URL을 전송할 수 있도록 한다. 완료되면 여러분의 패키지는 누구나 사용 할 수 있다!
continue reading [번역] 의존성 관리 도구 컴포저 - 라이브러리
라이브러리
이번 장은 컴포저를 통해서 설치할 수 있는 라이브러리를 만드는지 이야기할 것이다.모든 프로젝트는 패키지이다
디렉토리에서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"
}
참고: 여러분은 되도록이면 명시적으로 버전 항목을 지정하지 않도록 해야한다. 왜냐하면 태그 값은 태그 이름과 일치해야 하기 때문이다.
태그
버전처럼 보이는 모든 태그의 경우 해당 태그의 패키지 버전이 생성될 것이다. 패키지 버전은-patch
(-p
), -alpha
(-a
), -beta
(-b
), RC
의 선택적인 접미사와 함께 '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
참고: 여러분의 태그가 v로 시작할지라도require
구문에서 버전 제약은 접두사 없이 지정해야한다. (예: 태그v1.0.0
은 버전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을 전송할 수 있도록 한다. 완료되면 여러분의 패키지는 누구나 사용 할 수 있다!