2015-07-16

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

* 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"
}
참고: 여러분은 되도록이면 명시적으로 버전 항목을 지정하지 않도록 해야한다. 왜냐하면 태그 값은 태그 이름과 일치해야 하기 때문이다.

태그

버전처럼 보이는 모든 태그의 경우 해당 태그의 패키지 버전이 생성될 것이다. 패키지 버전은 -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.02.0.x-dev 버전을 얻는다 (.x는 브랜치로 인식하기 위해 기술적인 이유로 추가됨). 또한 2.0.x 브랜치는 유효할 뿐 아니라 2.0.x-dev로 전환된다. 만약 브랜치가 버전과 같지 않으면 dev-{branchname}가 될 것이다. masterdev-master 버전이 된다.

다음은 버전 브랜치 이름에 관련된 예시이다.
  • 1.x
  • 1.0 (1.0.x와 같음)
  • 1.1.x
참고: 여러분이 개발 버전을 설치하면 그 source에서 자동으로 가져올 것이다. 더 자세한 내용은 install를 참고하라.

별칭

버전에 브랜치 별칭을 지정할 수 있다. 예를 들어 여러분은 dev-master1.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을 전송할 수 있도록 한다. 완료되면 여러분의 패키지는 누구나 사용 할 수 있다!

continue reading [번역] 의존성 관리 도구 컴포저 - 라이브러리
Share This:    Facebook Twitter

2015-07-09

[번역] 의존성 관리 도구 컴포저 - 기본 사용법(Basic usage)

개인 소장용으로 번역한 자료입니다.
참고용으로만 봐주시고, 틀린 점이 있으면 언제든 태클 걸어주세요.

* url: https://getcomposer.org/doc/01-basic-usage.md

기본 사용법

소개

기본 사용법을 소개하면서 로깅 라이브러리인 monolog/monolog를 설치할 것이다. 아직 컴포저를 설치하지 않았다면 소개 장을 참조하라.
참고: 단순화를 위해 이 소개는 컴포저의 로컬 설치를 가정할 것이다.

composer.json: 프로젝트 세팅

프로젝트에 컴포저를 사용하기 위해서 여러분은 composer.json 파일이 필요하다. 이 파일은 여러분의 프로젝트의 의존성에 대해서 기술할 뿐 아니라 다른 메타데이터도 포함할 수 있다.

require

composer.json에서 지정할 첫 번째 (또는 자주 할) 일은 require 키이다. 여러분은 프로젝트에 의존하는 패키지를 컴포저에 간단히 지정할 수 있다.

{
    "require": {
        "monolog/monolog": "1.0.*"
    }
}
보다시피 require은 패키지 이름 (예: monolog/monolog) 을 패키지 버전 (예: 1.0.*) 으로 매핑한 객체를 가져온다.

패키지 이름

패키지 이름은 벤더 이름과 프로젝트 이름으로 구성된다. 보통 벤더 이름과 프로젝트 이름은 동일하다. 벤더 이름은 그저 이름 충돌을 막기 위해 존재하기 때문이다. 벤더 이름은 서로 다른 두 사람이 각각 igorw/jsonseldaek/json으로 json이라는 같은 이름의 라이브러리를 생성할 수 있도록 한다.

우리는 여기서 monolog/monolog를 요구하고 있고 벤더 이름은 프로젝트의 이름과 동일하다. 고유한 프로젝트 이름을 사용하는 것이 좋다. 나중에 같은 네임스페이스 아래서 연관된 프로젝트를 많이 추가할 수 있기 때문이다. 여러분이 라이브러리를 유지한다면 더 작은 부분으로 나누기 쉬울 것이다.

패키지 버전

이전 예제에서 우리는 모놀로그 버전 1.0.* 을 요청했다. 이는 1.0 개발 브랜치의 버전을 의미한다. 그 버전은 >=1.0<1.1과 일치하는 버전에 해당한다.

버전 제약은 몇 가지 방법으로 지정할 수 있고 이 주제에 대한 자세한 정보는 버전 문서를 참조하라.

안정성

기본적으로 안정된 릴리즈만 대상으로 한다. 만약 의존성의 RC, 베타, 알파, 개발 버전을 얻으려면 안정성 플래그를 사용하여 얻을 수 있다. 의존성 하나당 수행하는 것 대신 모든 패키지를 변경하려면 여러분은 최소 안정성 설정을 사용할 수 있다.

의존성 설치

프로젝트에서 정의된 의존성을 설치하려면 그저 install 명령어를 실행하면 된다.

php composer.phar install
이 명령어는 제공된 버전 제약과 일치하는 monolog/monolog의 최신 버전을 찾고 vendor 디렉토리로 다운로드 한다. 이것은 vendor라는 디렉토리로 외부 코드를 놓는 규약이다. 모놀로그의 경우 vendor/monolog/monolog로 놓는다.
팁: 여러분의 프로젝트가 git을 사용한다면 아마 vendor.gitignore에 추가해야 한다. 절대 저장소의 모든 코드를 추가하면 안된다.

여러분은 install 명령이 composer.lock 파일도 만들었다는 것을 알 수 있다.

composer.lock - 잠금파일

의존성 설치 후 컴포저는 composer.lock 파일에 설치해야 할 정확한 버전 리스트를 작성할 것이다. 이것은 특정 버전으로 프로젝트를 고정한다.

버전 컨트롤에 애플리케이션의 (composer.json과 함께) composer.lock을 커밋한다.

이 내용은 중요하다. 왜냐하면 잠금파일이 존재하면 install 명령어는 체크하여 그곳에 (composer.json에 뭐라고 적혀있든지) 지정된 버전을 다운로드 하기 때문이다.

잠금 파일을 커밋하는 것은 프로젝트를 설정하는 그 누구도 의존성에서 정확히 같은 버전을 다운로드 하지 않을 것을 의미한다. 여러분의 CI 서버, 생산 기기, 여러분 팀의 다른 개발자, 모든 것과 모두는 구축하는 일부에 영향을 미치는 버그를 완화하는 동일한 의존성에서 실행한다. 심지어 여러분이 프로젝트 재설치로 6달 동안 혼자 개발할 때도 새로운 버전으로 많이 릴리즈 되더라도 설치된 의존성은 여전히 동작한다고 느낄 수 있다.

만약에 composer.lock 파일이 없으면 컴포저는 composer.json에서 의존성과 버전을 읽고 updateinstall 명령어를 실행한 후에 잠금 파일을 만들 것이다.

잠금 파일을 만든다는 것은 의존성의 새로운 버전이 나오더라도 여러분은 자동으로 업데이트 받지 않는다는 것을 의미한다. 새로운 버전으로 업데이트 하려면 update 명령어를 사용한다. 그러면 매칭되는 (여러분의 composer.json 파일에 따라서) 최근 버전을 받을 것이고 새로운 버전으로 잠금파일을 갱신할 것이다.

php composer.phar update
참고: composer.lockcomposer.json 파일이 동기화되어 있지 않으면 install 명령어를 실행할 때 경고를 표시할 것이다.

만약 의존성 하나에만 설치나 업데이트를 원한다면 허용 목록에 추가할 수 있다.

php composer.phar update monolog/monolog [...]
참고: 라이브러리의 경우 잠금 파일을 반드시 커밋할 필요는 없다.
라이브러리-잠금파일 참고

패키지스트

패키지스트는 메인 컴포저 저장소이다. 컴포저 저장소는 기본적으로 패키지를 얻을 수 있는 곳인 패키지 소스이다. 패키지스트는 모두가 사용하는 중앙 저장소가 되는 것이 목표이다. 이것은 사용 가능한 어떤 패키지든 자동으로 require할 수 있다는 것을 의미한다.

패키지스트 웹사이트를 방문하면 여러분은 패키지를 둘러보고 검색할 수 있다.

컴포저를 사용하는 어떤 오픈 소스 프로젝트도 자신의 패키지를 패키지스트에 발행하는 것이 좋다. 라이브러리는 컴포저가 사용하는 패키지스트에 있을 필요는 없지만 다른 개발자들이 더 빠르게 탐색하고 도입할 수 있게 해준다.

오토로딩

컴포저는 자동으로 로드하는 정보를 지정한 라이브러리의 경우에 vendor/autoload.php 파일을 생성한다. 여러분은 간단하게 이 파일을 포함하고 자유롭게 오토로딩을 할 수 있다.

require 'vendor/autoload.php';
이 코드는 실제로 외부 코드를 사용하기 쉽게 해준다. 예를 들면 프로젝트가 모놀로그에 의존하고 있다면 여러분은 그저 클래스를 사용하면 자동으로 클래스를 불러온다.

$log = new Monolog\Logger('name');
$log->pushHandler(new Monolog\Handler\StreamHandler('app.log', Monolog\Logger::WARNING));

$log->addWarning('Foo');
여러분은 심지어 composer.json에서 autoload 항목을 추가하는 것으로 오토로더를 여러분의 코드에 추가할 수 있다.

{
    "autoload": {
        "psr-4": {"Acme\\": "src/"}
    }
}
컴포저는 Acme 네임스페이스로 PSR-4 오토로더를 등록할 것이다.

여러분은 디렉토리에서 네임스페이스 매핑을 정의한다. src 디렉토리는 여러분의 프로젝트 루트에서 vendor 디렉토리와 같은 단계가 될 것이다. 예제 파일이름은 Acme\Foo 클래스를 포함한 src/Foo.php가 될 것이다.

autoload 항목을 추가한 후에 여러분은 vendor/autoload.php 파일을 다시 생성하기 위해 dump-autoload를 재실행 해야한다.

해당 파일을 포함하는 것 또한 오토로더 인스턴스를 반환합니다, 그래서 여러분은 변수에 해당 반환값을 저장하고 네임스페이스를 더 추가할 수 있다. 예를 들어 이 예제는 테스트 프로그램에서 클래스를 자동으로 불러오는 데에 유용할 수 있다.

$loader = require 'vendor/autoload.php';
$loader->add('Acme\\Test\\', __DIR__);
PSR-4 오토로드에 추가적으로 컴포저에는 클래스 맵과 파일 오토로드인 PSR-0이 지원된다. 더 자세한 내용은 autoload 를 참조하면 된다.
참고: 컴포저는 자신의 오토로드를 제공한다. 만약 여러분이 제공하는 것을 사용하고 싶지 않다면 자신의 오토로드를 구성할 수 있도록 연관배열을 반환하는 vendor/composer/autoload_*.php 파일을 포함하면 된다.

continue reading [번역] 의존성 관리 도구 컴포저 - 기본 사용법(Basic usage)
Share This:    Facebook Twitter

2015-07-02

[번역] 의존성 관리 도구 컴포저 시작하기 - 소개(Intro)

컴포저에 대해서 소개글을 읽다보니 해석하느라 내용이 눈에 잘 안들어와서 번역 해 보았습니다. 시간 나면 다음 것도 번역해볼까 하지만, 발 번역이라 컴포저에 대한 국문 내용이 필요하신 분들께 죄송하네요. 이 글은 그냥 참고용으로만...

* url: https://getcomposer.org/doc/00-intro.md

소개s

컴포저는 PHP 의존성 관리 도구이다. 프로젝트에서 요구하는 의존 라이브러리를 선언하고 프로젝트에 설치하는 것을 도와준다.

의존성 관리

컴포저는 패키지 관리자가 아니다. 그렇다, "패키지"나 라이브러리를 다루기는 하지만 프로젝트 단위로 관리하고 프로젝트 디렉토리 (예: vendor) 안에서 설치 한다. 기본적으로 절대 전역 설치하지는 않는다. 그래서 의존성 관리자이다.

이 아이디어는 새로운 것은 아니며 컴포저는 nodejs의 npm이나 루비의 bundler에서 크게 영향을 받았다. 그러나 그 당시 PHP를 위한 도구같은 건 없었다.

컴포저는 다음과 같은 문제를 해결 해 준다.

a) 몇몇 라이브러리에 의존하는 프로젝트가 있다.
b) 어떤 라이브러리는 다른 라이브러리에 의존적이다.
c) 의존성을 선언한다.
d) 컴포저는 설치에 필요한 패키지의 버전을 찾아서 설치한다 (프로젝트에 다운 받는 것을 의미한다).

의존성 선언

프로젝트를 생성하고 로그 기록하는 라이브러리가 필요하다고 해보자. 여러분은 monolog를 사용하기로 결정했다. 프로젝트에 추가하기 위해 해야 할 일은 composer.json 파일에 프로젝트 의존성을 선언하는 것이다.

{
 "require": {
  "monolog/monolog": "1.2.*"
 }
}
우리는 프로젝트가 어떤 monolog/monolg 패키지를 요구하는지 간단하게 작성했다. 모든 버전은 1.2로 시작한다.

시스템 요구

컴포저는 PHP 5.3.2 이상이어야 동작한다. 몇몇 세심한 PHP 설정과 컴파일 표시가 필요하지만 설치 프로그램을 진행할 때 호환성에 대한 경고가 표시 된다.
간단한 zip 아카이브 대신에 소스 패키지를 설치하려면 패키지 버전 컨트롤에 따라 git, svn, hg가 필요하다.
컴포저는 멀티 플랫폼을 지원하고 우리는 윈도우, 리눅스, OSX에서 똑같이 동작하도록 노력하고 있다.

설치 - 리눅스 / 유닉스 / OSX

실행 가능 한 컴포저 다운로드

짧지만 컴포저를 설치하는데 2가지 방법이 있다. 프로젝트의 일부분으로서 지역적으로 또는 어디에서나 실행가능하도록 전역적으로 설치하는 방법이 있다.

지역 설치 (Locally)

컴포저 지역 설치는 그냥 프로젝트 디렉토리 안에서 실행하면 된다.

curl -sS https://getcomposer.org/installer | php
참고: 어떠한 이유로 실패하면 php 대신에 인스톨러를 다운받을 수 있다.

php -r "readfile('https://getcomposer.org/installer');" | php
인스톨러는 몇몇 PHP 설정을 체크하고 작업 디렉토리에 composer.phar 를 다운받을 것이다. 이 파일은 컴포저 바이너리 파일이다. PHAR (PHP 아카이브) 라고 하는데 다른 것들 사이에서 명령줄로 실행할 수 있는 PHP 아카이브 형식이다.

--install-dir 옵션을 사용하여 지정 디렉토리(절대 경로나 상대 경로일 수 있다)를 제공하는 것으로 컴포저를 특정 디렉토리에 설치할 수 있다.

curl -sS https://getcomposer.org/installer | php -- --install-dir=bin

전역 설치 (Globally)

여러분은 이 파일을 여러분이 원하는 어디에나 놓을 수 있다. 시스템 속성 PATH에 설정하면 여러분은 전역적으로 접근할 수 있다. 유닉스 시스템에서 심지어 php 없이 실행가능하게 하고 호출 할 수 있다.

여러분은 시스템 어디에나 쉽게 composer에 접근하기 위해서 이 명령어를 실행할 수 있다.

curl -sS https://getcomposer.org/installer | php
mv composer.phar /usr/local/bin/composer
참고: 권한 때문에 실패했다면 sudo 권한으로 mv 줄을 다시 실행하라.
참고: 요세미티 OSX에서 /usr 디렉토리는 기본적으로 존재하지 않는다.  "/usr/local/bin/composer: No such file or directory" 라는 에러가 나면  진행하기 전에 /usr/local/bin/ 폴더를 수동으로 생성한다.

그리고 나서 컴포저를 실행하기 위해 php phpcomposer.phar 명령 대신에 composer 명령을 실행한다.

설치 - 윈도우즈

인스톨러 이용하기

이 방법은 가장 쉽게 컴포저를 설정할 수 있는 방법이다.

Composer-Setup.exe를 다운로드 받고 실행한다. 최신 컴포저 버전을 설치하고 PATH 를 세팅하면 어느 디렉토리에서나 명령 줄로 composer 명령을 그냥 실행하는 것으로 호출할 수 있다.
참고: 현재 터미널을 닫는다. 새로운 터미널로 사용 테스트를 한다. 터미널 시작할 때 경로만 로드하기 때문에 중요하다.

수동 설치

환경변수 PATH 디렉토리를 변경하고 composer.phar를 다운 받을 수 있는 설치 조각을 실행한다.

C:\Users\username>cd C:\bin
C:\bin>php -r "readfile('https://getcomposer.org/installer');" | php
노트: 위의 readfile 때문에 실패한다면 http 주소를 사용하거나 php.ini에서 php_openssl.dll을 사용 설정 한다.

composer.phar 파일로 새 composer.bat 파일을 만든다.

C:\bin>echo @php "%~dp0composer.phar" %*>composer.bat

아직 설정되어 있지 않으면 환경변수 PATH에 디렉토리를 추가한다. 현재 터미널을 닫는다. 그리고 새 터미널을 열어서 테스트 한다.

C:\Users\username>composer -V
Composer version 27d8904


컴포저 이용하기

우리는 이제 컴포저로 프로젝트 의존성 설치할 것이다. 현재 디렉토리에 composer.json 파일이 없다면 기본 사용법 부분을 넘어가도 된다.

의존성을 해결하고 다운로드하기 위해서 install 명령어를 실행한다.

php composer.phar install
만약 전역 설치를 했고 그 디렉토리에 phar가 없다면 이 명령어를 실행하라

composer install
위의 의존성 선언 예제를 따라서 vendor/monolog/monolog 디렉토리로 monolog를 다운로드 받을 것이다.

오토로딩

라이브러리를 다운로드 받는 것 외에 컴포저는 다운로드한 라이브러리의 어떤 클래스든 자동으로 불러올 수 있는 오토로드 파일을 준비한다. 컴포저를 사용하기 위해서는 그냥 코드의 부트 스트랩 과정에 저 줄을 따라서 추가해주면 된다.

require __DIR__ . '/vendor/autoload.php';
와우! 이제 monolog를 사용할 수 있다! 컴포저에 대해서 더 배우고 싶으면 "기본 사용법" 장을 계속 읽으면 된다.

continue reading [번역] 의존성 관리 도구 컴포저 시작하기 - 소개(Intro)
Share This:    Facebook Twitter