public-mirrors
/
composer
mirror of https://github.com/composer/composer
1
0
Fork 0
Code

Merge pull request #339 from igorw/docs 

Docs: finish repositories, add community chapter
pull/341/head
Jordi Boggiano 2012-02-20 07:33:04 -08:00
parent 93ac0eb523 e4143f98c5
commit c1b8e308df
4 changed files with 143 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
README.md
View File

@ -97,6 +97,10 @@ merged. This is to ensure proper review of all the code.
Fork the project, create a feature branch, and send us a pull request.
To ensure a consistent code base, you should make sure the code follows
the [Coding Standards](http://symfony.com/doc/2.0/contributing/code/standards.html)
which we borrowed from Symfony.
If you would like to help take a look at the [list of issues](http://github.com/composer/composer/issues).
Community

2
doc/04-schema.md
View File

@ -288,7 +288,7 @@ Example:
"source": {
"url": "http://smarty-php.googlecode.com/svn/",
"type": "svn",
"reference": "trunk"
"reference": "tags/Smarty_3_1_7/distribution/"
}
}
}

110
doc/05-repositories.md
View File

@ -148,6 +148,116 @@ The VCS driver to be used is detected automatically based on the URL.
### PEAR
It is possible to install packages from any PEAR channel by using the `pear`
repository. Composer will prefix all package names with `pear-{channelName}/` to
avoid conflicts.
Example using `pear2.php.net`:
```json
{
"repositories": [
{
"type": "pear",
"url": "http://pear2.php.net"
}
],
"require": {
"pear-pear2/PEAR2_HTTP_Request": "*"
}
}
```
In this case the short name of the channel is `pear2`, so the
`PEAR2_HTTP_Request` package name becomes `pear-pear2/PEAR2_HTTP_Request`.
> **Note:** The `pear` repository requires doing quite a few requests per
> package, so this may considerably slow down the installation process.
### Package
If you want to use a project that does not support composer through any of the
means above, you still can define the package yourself using a `package`
repository.
Basically, you define the same information that is included in the `composer`
repository's `packages.json`, but only for a single package. Again, the
minimally required fields are `name`, `version`, and either of `dist` or
`source`.
Here is an example for the smarty template engine:
```json
{
"repositories": [
{
"type": "package",
"package": {
"name": "smarty/smarty",
"version": "3.1.7",
"dist": {
"url": "http://www.smarty.net/files/Smarty-3.1.7.zip",
"type": "zip"
},
"source": {
"url": "http://smarty-php.googlecode.com/svn/",
"type": "svn",
"reference": "tags/Smarty_3_1_7/distribution/"
}
}
}
],
"require": {
"smarty/smarty": "3.1.*"
}
}
```
Typically you would leave the source part off, as you don't really need it.
## Hosting your own
While you will probably want to put your packages on packagist most of the time,
there are some use cases for hosting your own repository.
* **Private company packages:** If you are part of a company that uses composer
for their packages internally, you might want to keep those packages private.
* **Separate ecosystem:** If you have a project which has its own ecosystem,
and the packages aren't really reusable by the greater PHP community, you
might want to keep them separate to packagist. An example of this would be
wordpress plugins.
When hosting your own package repository it is recommended to use a `composer`
one. This is type that is native to composer and yields the best performance.
There are a few different tools that can help you create a `composer`
repository.
### Packagist
The underlying application used by packagist is open source. This means that you
can just install your own copy of packagist, re-brand, and use it. It's really
quite straight-forward to do.
Packagist is a Symfony2 application, and it is [available on
GitHub](https://github.com/composer/packagist). It uses composer internally and
acts as a proxy between VCS repositories and the composer users. It holds a list
of all VCS packages, periodically re-crawls them, and exposes them as a composer
repository.
To set your own copy, simply follow the instructions from the [packagist
github repository](https://github.com/composer/packagist).
### Satis
Satis is a static `composer` repository generator. It is a bit like a ultra-
lightweight, file-based version of packagist.
You give it a `composer.json` containing repositories, typically VCS and package
repository definitions. It will fetch all the packages that are `require`d from
these repositories and dump a `packages.json` that is your `composer`
repository.
Check [the satis GitHub repository](https://github.com/composer/satis) for more
information.

28
doc/06-community.md Normal file
View File

@ -0,0 +1,28 @@
# Community
We have a lot of people using composer, and also many contributors to the
project.
## Contributing
If you would like to contribute to composer, please read the
[README](https://github.com/composer/composer).
The most important guidelines are described as follows:
> All code contributions - including those of people having commit access - must
> go through a pull request and approved by a core developer before being
> merged. This is to ensure proper review of all the code.
>
> Fork the project, create a feature branch, and send us a pull request.
>
> To ensure a consistent code base, you should make sure the code follows
> the [Coding Standards](http://symfony.com/doc/2.0/contributing/code/standards.html)
> which we borrowed from Symfony.
## IRC / mailing list
The developer mailing list is on [google groups](http://groups.google.com/group
/composer-dev) IRC channels are available for discussion as well, on
irc.freenode.org [#composer](irc://irc.freenode.org/composer) for users and
[#composer-dev](irc://irc.freenode.org/composer-dev) for development.