퍼블리싱 패키지(Publishing Packages)

{
    "name": "your-vendor-name/package-name",
    "description": "A short description of what your package does",
    "require": {
        "php": ">=5.3.0",
        "another-vendor/package": "1.*"
    }
}

시작하기

의존성정의(Define Your Dependencies)

프로젝트 루트(root)에 당신의 프로젝트 의존성을 갖고있는 composer.json 라는 이름의 파일을 놓는다:

{
    "require": {
        "vendor/package": "1.3.2",
        "vendor/package2": "1.*",
        "vendor/package3": "^2.0.3"
    }
}

패키지버전 사용에대한 더 많은 정보는 composer documentation.를 참고하라.

프로젝트에 컴포저 설치(Install Composer In Your Project)

커맨드라인에 다음을 실행한다:

curl -sS https://getcomposer.org/installer | php

아니면 download composer.phar 를 프로젝트에 다운로드한다.

여러 플랫폼에대한 설치방법은 컴포저 문서( installation instructions )를 참고하라.

의존성설치(Install Dependencies)

다음을 프로젝트 루트(root)에서 실행한다.

php composer.phar install

Autoload Dependencies

만일 당신의 패키지가 오토로딩정보( autoloading information )를 명시했다면  다음의 것을 당신의 코드에 추가함으로써 모든 의존성을 오토로드(autoload) 할 수 있다:

require 'vendor/autoload.php';

Browse the packages we have to find more great libraries you can use in your project.

라이브러리(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

기본사용법

인트로

기본 사용법을 위해 로깅 라이브러리인  monolog/monolog, 를 설치할 것이다. 만일, 아직 컴포저를 설치하지 않았다면  Intro 를 참조하라.

주의: 단순함을 위해 이 글은 당신이 컴포저의 로컬 인스톨(a local install of Composer)을 수행한다고 가정한다.

composer.json: 프로젝트셋업

프로젝트에서 컴포저를 시작하려면 composer.json 파일이 필요하다. 이파일은 프로젝트의 의존성을 나타내고 다른 메타데이터도 포함할 수 있다.

require 키

 composer.json 에 처음으로 명시해야할 것은(종종 유일할 수도 있음) require 키 이다. 이는 컴포저에게 프로젝트가 어떤 패키지에 의존하고있는지를 말하는 것이다

{
    "require": {
        "monolog/monolog": "1.0.*"
    }
}

보다시피, require 는  패키지네임(package names) (e.g. monolog/monolog) 을 버전제약(version constraints) (e.g. 1.0.*)로 맵핑하는 오브젝트(object)를 취한다.

패키지네임(Package Names)

패키지네임은 벤더네임(vendor name)과 프로젝트네임으로 구성된다. 종종 이둘은 동일하다-벤더네임은 단지  네이밍충돌(naming clashes)을 막으려고 존재한다. 이는 두사람이  json이라고 명명된 하나의 라이브러리를 만들수 있도록 하는데 이는 igorw/json 과seldaek/json으로 이름지어질 수도 있다. 

우리의 예에서는 monolog/monolog을 요구하는데 따라서 벤더네임이 프로젝트네임과 같다. 프로젝트를위해선 유니크(unique)한 네임이 추천된다. 이는 나중에 같은 네임스페이스아래서 더 많은 프로젝트를 추가할 수 있도록해준다. 만일 당신이 라이브러리를  관리하고있다면 더 작은 디커플된 파트(smaller decoupled parts)로 나누는 것을 쉽게해준다.

패키지버전(Package Versions)

이전예에서 우리는 Monolog의  1.0.* 버전을 요구하고 있었다. 이것은  1.0개발브랜치(development branch)의 모든 버전을 의미한다. 이는  >=1.0 <1.1와 매치하는 버전들을 말하는 것과 동일하다.

버전제약(Version constraints)은 여러방식으로 명시될 수 있다. 이 토픽에대한 더깊은 설명은  versions 을 참조하라.

안정성(Stability)

디폴트로 오직 안정화된 릴리즈(stable releases)만이 고려대상이 된다. 만일, RC, beta, alpha 혹은 dev 버전을 원한다면  stability flags. 을 사용하여 그렇게 할 수 있다. 의존성 하나 하나 당 하는 것 대신 모든 패키지를 일괄적으로 하고싶다면 minimum-stability 세팅을 사용할 수 있다(To change that for all packages instead of doing per dependency you can also use the minimum-stability )

의존성 설치(Installing Dependencies)

프로젝트를 위한 정의된 의존성을 설치하려면 install 커맨드를 실행한다.

php composer.phar install

이는 제공된 버전제한(version constraint)에서 monolog/monolog 의  최신버전을 찾아  vendor 디렉토리에 다운로드할 것이다.  vendor. 이라는 디렉토리에 써드파티(third party) 코드를 넣는 것이 컨벤션(convention)이다. Monolog 경우는vendor/monolog/monolog.에 넣을 것이다.

팁: 만일 프로젝트를위해 git를 사용한다면, .gitignore에vendor를 추기하기를  원할 수 도 있다.

 당신은 정말 모든 코드를 당신의 저장소(repository)에 넣기를 원치않을 것이다.

당신은 install 커맨드가  composer.lock 파일도 만든다는 것을 발견할 것이다..

composer.lock - The Lock File

의존성을 설치하고 난 다음 컴포저는  composer.lock 파일에 설치된 정확한 버전의 목록을 작성한다. 이것은 프로젝트를 이 특정한 버전들에 잠가버린다.

당신의 애플리케이션의 composer.lock (composer.json과함께 )을 버전콘트롤에 커밋(Commit).

이것은 중요한데 왜냐하면 install 커맨드가  lock 파일이 존재하는지 확인하고 존재한다면 명시된 버전을 다운로드하기때문이다(composer.json 가 어떤 이야기를 하던간에).

이것은 프로젝트를 셋업한 누구나 의존성의 정확한 버전을 다운로드할 것이라는 의미이다. 당신의  CI 서버, 프로덕션 머신(production machines), 팀내의 다른 개발자들, 모든 것 그리고 모든 사람들이 동일한 의존성을 사용한다는 의미인데 이는 버그의 가능성을 경감시켜서 드플로이먼트(deployments)의 제한된 부분에만 영향을 미치게한다. 심지어 당신이 혼자 개발을 한다해도 6개월 후에 프로젝트를 재설치할때 심지어 의존성 릴리즈가 그 후로 많은 새로운 버전이 있다해도 당신은 설치된 의존성이 여전히 제대로 작동할 것이라고 확신을 가질수 있다.

만일 composer.lock 파일이 없다면 컴포저는 composer.json에서 의존성과 버전을 읽고 update 혹은 install 커맨드를 실행 후 lock 파일을 생성할 것이다.

이말은 만일 의존성 중에 새로운 버전이 있다면 자동으로 업데이트되지 않는다는 뜻이다. 새로운 버전을 업데이트하려면 update 커맨드를 사용한다. 그러면 최신의 부합되는 버전을 가져오고(composer.json 파일에 근거해서) 또 새로운 버전에따라  lock 파일을 업데이트한다..

php composer.phar update

주의: 컴포저는 composer.lock과 composer.json 가 싱크(synchronized)하지 않다면 install 커맨드를 실행할때 경고싸인을 표시한다.

만일, 단지 하나의 의존성을 설치 혹은 업데이트하고자 한다면 당신은 이를 백서작성(whitelist) 할 수 있다:

php composer.phar update monolog/monolog [...]

주의: 라이브러리를 위해서는 파일을 커밋하는 것이 필요치 않다., see also: Libraries - Lock file를 참조하라

Packagist

Packagist 는 메인 컴포저 저장소(repository)이다. 컴포저 저장소는 기본적으로 패키지 소스(package source)이다(당신이 패키지를 얻을 수 있는 장소). Packagist 는 모든 사람들이 사용할 수있는 중앙저장소(central repository)를 목적으로한다. 이말은 이곳에서 이용가능한 모든 패키지를 자동으로  require 할 수 있다는 뜻이다.

 Packagist website (packagist.org)에 가면 패키지를 둘러보고나 검색할 수있다. 컴포저를 사용하는 모든 오프소스 프로젝트는  Packagist에 그들의 패키지를 퍼블리싱하기를 추천한다. 라이브러리는 컴포저로 사용되기위해 Packagist 에 꼭 있어야하는 것은 아니지만  Packagist 에 있으면 다른 개발자들이 이을 찾고 적용하는 것을 편리하게 해준다.

오토로딩(Autoloading)

오토로드(autoload) 정보를 명시한 라이브러리(libraries) 는  vendor/autoload.php 파일을 컴포저가 생성한다. 당신은 단지 이 파일을 포함하면 무료로 오토로딩을 얻게된다. 

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

이는 써드파티 코드를 사용하기 쉽게한다. 예를들어, 당신의 프로젝트가 Monolog를 의존한다면, 당신의 그로부터 클래스들을 사용하기 시작할 수있다. 그리고 그들은 모두 오토로딩 될 것이다.

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

또, autoload 파일을  composer.json 에 추가함으로써 당신은 당신 자신의 코드를 오토로더에 추가할 수 있다.

{
    "autoload": {
        "psr-4": {"Acme\\": "src/"}
    }
}

컴포저는  Acme 네임스페이스를위한  PSR-4 오토로더를 등록할 것이다.

당신은 네임스페이스와 디렉토리(directories) 사이의 맵을 정의할 수 있다(You define a mapping from namespaces to directories.)  vendor 디렉토리가 동일한 레벨(level)에서 그렇듯이 src 디렉토리가 당신의 프로젝트 루트에 있을 것이다.  src/Foo.php  Acme\Foo 클래스를 갖고있는  src/Foo.php  를 예로들어보자.

autoload 파일을 추가한 후, vendor/autoload.php 파일을 재생성하기위해  dump-autoload 을 재실행해야한다

그 파일을 포함(Including) 하는 것은 오토로더 인스턴스(autoloader instance)를 리턴한다. 따라서 당신은 그 인클루드콜(include call)의 리턴값을 저장할 수  있고  더 많은 네임스페이스를 추가할 수 있다. 이는 태스트 슈트에서의 오토로딩클래스에 유용하다, 예를들면(This can be useful for autoloading classes in a test suite, for example.)

$loader = require __DIR__ . '/vendor/autoload.php';
$loader->add('Acme\\Test\\', __DIR__);

PSR-4 오토로딩 뿐만 아니라, 컴포저는 PSR-0, 클래스맵(classmap) 그리고 파일 오토로딩(files autoloading)도 지원한다. autoload 참조하라

주의:컴포저는 그 자체의 오토로더를 제공한다. 만일 이를 사용하기를 원하지 않는다면 당신은 단지 vendor/composer/autoload_*.php 파일을 인클루드할 수 있다. 이는 당신이 당신 자신의 오토로더를 설정할 수 있는 연관배열(associative arrays)을 리턴한다.

원문 : https://getcomposer.org/doc/01-basic-usage.md

소개

컴포저(Composer)는 PHP의 의존성관리 툴이다. 이는 프로젝트가 의존하는 라이브러리를 선언할 수 있게 해주고 또 이들을 관리(설치/업데이트)해준다.

의존성관리(Dependency management)

컴포저는 Yum, 혹은 Apt같은 패키지매니저가 아니다. 패키지 혹은 라이브러리를 다루지만  컴포저는 이들을 프로젝트 베이스로 관리(프로젝트 내부의 디렉토리(예:vendor)에 설치하는)를 할 뿐이다. 디폴트로 컴포저는 어떠한 것도 전역적으로(글로벌하게, globally) 설치하지 않는다. 즉, 컴포저는 의존성매니저(관리자)이다. 그러나, 컴포저는 글로벌 커맨드(global command)를 통해서 편의상 "글로벌" 프로젝트를 지원한다. 

이런 아이디어는 새로운 것은 아니며 컴포저는 노드의 npm(node's npm)과 루비의 번들러(ruby's bundler)로부터 많은 영감을 얻었다.

가정:

1. 당신은 많은 라이브러리에 의존하는 프로젝트를 가지고 있다.
2. 이들 라이브러리 중 일부는 다른 라이브러리에 의존한다.

컴포저:

1. 당신이 의존하는 라이브러리를 선언하게 한다.
2. 어떤 패키지의 어떤 버전이 필요한지를 찾고 이를 설치한다(당신의 프로젝트에 다운로드 한다는 의미임).

시스템요건(System Requirements)

컴포저를 사용하려면 PHP 5.3.2+가 필요하다. 또, 약간의 민감한 PHP 세팅과 컴파일플래그(compile flags)도 필요하다. 그러나 인스톨러(installer)를 사용하면 비호환성(incompatibilities)에대한 경고멧세지를 받을 것이다. 

심플 짚 아카이브(simple zip archives) 대신에 소스(sources)로부터 패키지를 설치하려면 패키지가 어떻게 버전콘트롤(version-controlled)되는지에따라 git, svn 혹은 hg이 필요할 것이다. 

컴포저는 멀티플랫폼(multi-platform)이며 우리는Windows, Linux, OSX에서  똑같이 작동되도록 노력하고있다.

설치- Linux / Unix / OSX

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

컴포저는 당신이 커맨드라인(commandline)으로부터 직접적으로 실행할 수 있는 편리한 인스톨러(installer)를 제공한다.  download this file 을 다운로드하거나 혹은 당신이 인스톨러의 내부작동을 더 알고싶다면  GitHub 에서 알아보라. 소스는 PHP이다.

요약하면, 컴포저를 설치하는데는 2가지 방법이있다. 지역적(로컬리, Locally)으로 프로젝트의 일부분으로써, 글로벌(전역적으로,globally)하게는 시스템전체적인 실행으로(as a system wide executable.)

Locally

컴포저를 지역적으로 설치하는 것은  프로젝트 디렉토리에서 인스톨러를 작동시키는 문제이다.  the Download page 를 참고하라.

인스톨러는 몇가지 PHP 세팅사항을 확인하고 composer.phar 를 작업 디렉토리에 다운로드한다. 이 파일은 컴포저 바이너리(Composer binary)이다. 즉, PHAR (PHP 아카이브), 커맨드라인에서 실행될 수있는 PHP를 위한 아카이브포멧(archive format)이다. 

이제 컴포저를 작동시키기위해 php composer.phar 를 실행하라.

--install-dir 옵션을 사용하여 특정의 디렉토리에 컴포저를 설치할 수있고 --filename 옵션을 사용하여 이를 네임/리네임((re)name) 할 수 있다. 인스톨러를 사용할 때는,  the Download page instructions 을 따를 때 다음의 매개변수(parameters)를 추가하라:

php composer-setup.php --install-dir=bin --filename=composer

이제 컴포저를 사용하기위해 php bin/composer 을 실행하라.

Globally

Composer PHAR 는 원하는 어느 곳에도 위치시킬 수있다. 당신의 PATH, 의 일부분인 디렉토리에 놓았다면  당신은 이에 전역적으로(글로벌리, globally) 접근할 수있다. 심지어 UNIX계열 시스템이서는 

php 인터프리터(interpreter)의 사용없이도 이를 실행가능하게(make it executable)하고 호출(invoke) 할 수 있다 .

인스톨로를 작동시키고 난 다음에  the Download page instructions 를 보라. composer.phar를 당신의 path에 있는 디렉토리에 옮기기위해 이를 실행할 수 있다:

mv composer.phar /usr/local/bin/composer

주의: 퍼미션때문에 위의 파일이 실패한다면 sudo와 함께 다시 실행해보라.

주의: OSX 의 몇몇 버전은 디폴트로 /usr 디렉토리가 존재하지 않는다. 만일 "/usr/local/bin/composer: No such file or directory" 에러를 받으면 먼저 디렉토리를 수작업으로 생성하고 진행하라: mkdir -p /usr/local/bin.

주의: PATH를 변경하는 정보는 ,  Wikipedia article 를 읽고 구글을 이용하라

이제 php composer.phar대신에  composer 을 사용해서  컴포저를 실행해보라.

설치 - Windows

인스톨러 사용

이것은 당신의 머신(machine)에 컴포저를 셋업하는 가장 쉬운 방법이다.

Composer-Setup.exe. 을 다운로드해서 실행하라. 컴포저의 최신버전을 설치하고 PATH 을 셋업하기때문에 당신은 모든 디렉토리에서 커맨드라인으로  composer 를 호출할수있다.

주의: 현재의 터미널(terminal)을 닫아라. 새로운 터미널로 사용법을 테스트하라. 이는 중요하다. 왜냐하면 PATH는 터미널이 시작할 때만 로딩되기때문이다.

수동설치

당신의 PATH 에 있는  디렉토리로 변경 ->  the Download page instructions 을 따라 인스톨러를 실행하여 composer.phar를 다운로드한다.

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

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

 아직 추가되지 않았다면 PATH 환경변수에 디렉토리를 추가.  PATH 변수를 변경하는 것에대한 정보는 this article 보거나 Google을 이용하라.

현재의 터미널을 닫고  새로운 터미널로 사용법을 테스트하라:

C:\Users\username>composer -V
Composer version 1.0.0 2016-01-10 20:34:53

컴포저 사용하기

이제 컴포저를 설치하였다. 사용할 준비가 되었다. 다음 글에서 사용법이 이어진다

원문 : https://getcomposer.org/doc/00-intro.md