I downloaded Laravel from github and save it on c:/htdocs/laravel1
and I created a copy of my laravel with CMD (with composer) and I install this as laravel2 in c:/htdocs/laravel2 directory.
Laravel1:
c:/htdocs/laravel1
Laravel2:
c:/htdocs/laravel2
And I have access to both of them in localhost:8080/laravel1/public/ and
localhost:8080/laravel2/public/
My question is : Why should I install laravel by composer? There is no different between the installed laravel and downloaded laravel.
There are many, many valid reasons to use composer:
Composer creates optimized autoloaders if you want it to
Allows you to add thrird party dependencies easily (just add them to composer.json)
You can track the composer.lock file, and use composer install to ensure the exact same versions of the dependencies are being used throughout (on all environments, by everyone contribbuting) This is a must-have, if you're using automated builds!
Updating all dependencies, including Laravel, is a simple matter of composer update
Composer supports post-install and post-update scripts, to be executed after a composer install/update is run. This is quite commonly used to prompt the dev for configuration parameters. Downloading the code means you have to edit the config files by hand, and worse of all: track them in git or svn
... I'll probably add more reasons along the way, these are just a few off the top of my head
Update:
Just thought of some more reasons why using composer is a good idea:
Composer packages themselves can, and often do, define dependencies and requirements. Things like "php": ">=5.4.0", or "ext-curl": "*" will alert you to any missing PHP extensions or a version mismatch. These requirements can also trigger composer to fetch additional dependencies. Which brings me on to the next point:
Laravel itself has dependencies: Laravel uses components from Symfony2, for example. The easiest way to manage its own dependencies is to use composer, seeing as Symfony does, too. If you run composer update, the dependencies of Laravel will be checked, and updated where needed. Doing this manually is possible, but it's tedious, and really not worth the bother. Repetitive, dull jobs make people grumpy. Computers don't have this problem.
Composer is a dependancy manager similar to node's npm which allows quick and easy management of 3rd party libraries & packages on a per-project basis.
I recommend reading https://getcomposer.org/doc/00-intro.md to find out more about composer and explore https://packagist.org to find out the kind of things that are available through composer
I'm working on a project which contains couple of parts written in different languages. One of these parts is a PHP application. When distributing the project there is a phase to distrib this PHP app. I use Phing for that. So apart from other dependencies, I have
"require": {
"php": ">=5.3.13",
"phing/phing": "2.7.*"
}
As composer.json in Phing package suggests, Composer creates autoload_classmap entries for Phing. There are some Phing targets that copy vendor libraries further, but they don't copy Phing itself (it's not a runtime dependency for PHP project itself). As a consequence, there are many entries in autoload_classmap that are problematic. My application itself uses classmaps so I want to use the mechanism but not for all packages.
Is it possible to suppress generation of classmap entries on a per package basis ?
This is probably a hen-and-egg problem, but I think Phing does not belong into the softwares dependencies, so it has to be taken out. Problem with the classmap solved.
Where does it belong? It is infrastructure you have to install to deploy or distribute the software. Phing should be installed on the machine executing the deployment, or anywhere else where it is needed, but this is part of the infrastructure requirement for this machine.
You can use Composer to install Phing globally (it's way better than using PEAR for this). Or you can create a deployment project that includes Phing, probably other stuff, and has the task to deploy/distribute that software.
I am working with Behat and Composer for a project at work. I had to create a fork and patch for Mink and the Mink Selenium 2 driver to handle popup windows. Currently the patches are still being reviewed by those that manage the repos I forked. So in the mean time I would like to use my fork versions instead.
I have added my repositories to composer and they are being pulled in. However the "behat/mink" package is still being installed because the "behat/mink-extension" requires it. The thing is it can use my fork of it too. So I would like to have it pull in only mine and not the "behat/mink" package.
Can I do this? Can I block a package's required package in favor of my fork?
Thanks!
Yes, all you need to do is list your fork as a repository to use and Composer will automatically include the fork in preference to the original package. From the documentation
If you are using a certain library for your project and you decide to
change something in the library, you will want your project to use the
patched version. If the library is on GitHub (this is the case most of
the time), you can simply fork it there and push your changes to your
fork. After that you update the project's composer.json. All you have
to do is add your fork as a repository and update the version
constraint to point to your custom branch.
An example where someone has patched Monolog. They then tell Composer to use their repository.
{
"repositories": [
{
"type": "vcs",
"url": "https://github.com/igorw/monolog"
}
],
"require": {
"monolog/monolog": "dev-bugfix"
}
}
Composer will scan all the versions available in https://github.com/igorw/monolog and use them in preference to the version of Monolog available on Packagist.
You can also tell Composer to use local directories rather than an HTTP address.
"repositories": [
{
"type": "vcs",
"url": "/documents/project/igorw/monolog"
}
],
This allows you to develop library, use it in another project and test it without having to push to Github between each edit and test.
You cannot really block them. You might be able to disable the fetching of info from packagist.org, but this will affect all packages.
What you should do is add an alias for behat/mink. See the documentation of composer aliases.
Try to avoid branch aliases, use the inline alias.
I'm looking to develop a package in PHP, but I don't want it immediately available on GitHub or somewhere. It's easy enough to include a Packagist file in my composer.json, but how do I add a local package into my composer.json? Also, should I be building the package in /vendor/foo/bar (relative to the root composer.json), or should I put it somewhere else?
Edit: I guess my question is about how everyone else writes their packages. Does every new package get added to Packagist, and then when you want to test your changes, you commit to GitHub (or wherever), and then pull that back down via Composer? That seems really inefficient.
Instead of creating a new repository, you can tell composer to use any local path:
https://getcomposer.org/doc/05-repositories.md#path
For instance, lets say that you have your PHP projects under ~/devel/projects
You may have your main project in ~/devel/projects/main_project, and your "local package" in ~/devel/projects/local_package
Define your composer configuration for the local package. In ~/devel/projects/local_package/composer.json.
{
"name": "your_vendor_id/your_local_package",
...
}
Then, you can edit ~/devel/projects/main_project/composer.json and link to your local package via path repo:
"repositories": [
{
"type": "path",
"url": "../local_package",
"options": {
"symlink": true
}
}
],
"require": {
"your_vendor_id/your_local_package": "dev-master",
...
}
More info on this link (not written by me but has a good explanation on this subject):
https://carlosbuenosvinos.com/working-at-the-same-time-in-a-project-and-its-dependencies-composer-and-path-type-repository/
As this question has many different components/standards to be explained, I'll try to explain as much as possible here and you can PM me or just Google it for more specific questions as they come up.
To answer your first question, "How do I add a local package into my composer.json?":
If by "add local package" you mean autoload your class/package, you can do that by either using PSR-4 or PSR-0 or Classmap options in composer.
Read more
PSR [petermoulding.com] (via archive.org)
PSR-4 autoloading support in Composer [seld.be]
Battle of the Autoloaders: PSR-0 vs. PSR-4 [Sitepoint]
Why use a PSR-0 or PSR-4 autoload in composer if classmap is actually faster? [SO]
You can Google it if you need more info on PSR-0, PSR-4 and Classmap.
Example
"autoload": {
"psr-4": { "Core\\": "src/Core" } ## "standard": { "namespace" : "path/to/dir"}
}
Or (edit)
If you actually want to add a local package:
Create a composer.json for the local package, like:
{
"name": "localPackage/core",
"version": "dev-master"
}
You can also specify other properties and/or dependencies as required.
Zip the package, with the composer.json file as the root file in the archive.zip, and place it where desired.
In the other project/package where you want to include the local package, add the local package name to the required parameter, like
"localPackage/core": "dev-master"
Add the following under the repositories parameter:
"repositories" : [
{
"type": "artifact",
"url": "path/to/localPackage.zip"
}
]
Now if you have the local package on git, then there would be no need to archive the package (basically omit step 2) and you just need to replace the URL in the above example to the path/to/localPackage/.git.
(End of edit)
Now to answer the larger question: "How do I develop and include a Composer package?":
Decide the directory structure. Commonly it is as follows:
/PackageRoot
/src/PackageCore
composer.json ## this is your library’s composer.json
LICENSE
and set up your composer.json.
An example of one of mine composer.json files can be found at http://pastebin.com/tyHT01Xg.
Upload it to Github and tag the version. Use Semantic versioning (make sure you exclude/ignore the vendor directory when uploading to Github).
Register the package with Packagist (after logging in).
If you have tagged your commit as v1.0.0 (or similar), then this will show up in your Packagist dashboard for that package.
Now, if everything is done right, you should be able to use your library as a dependency in other projects by adding it to the composer.json of that project.
Here's a recap of the solutions plus my own
publish on packagist
Since you don't want to publish yet, you're in development, this is a poor option.
upload github
You may not want to publish your library source on github, not want to pay for a private repo, or be able to use a cloud external service (due to political or network policies).
zip your library
You can use the composer repository path in your example implementation to point to a local zip file as a release. You'll have to re-zip every time you make a change to the lib, even with a batch file to do it, this is icky.
upload to local git/svn repo on your machine
This is getting close, but you'll need to do a composer update each time you change your library and want to test your example implementation. This mimics productions but is cumbersome. Personally I recommend this solution, even though it's not brainless.
Autoload the library directly (sortof does what you want)
This is a hack, but you could just add:
{
"require": {
},
"autoload": {
"psr-4": {
"yourlibnamespace": "D:\\Code\\yourlib\\src\\"
}
}
}
Please note that you will need to copy+paste the 'require' section from your lib to your sample implementation. Change 'yourlibnamespace' to your library namespace and "D:\Code\yourlib\src\" to your local path to your library source.
This way any changes are immediately reflected. However you will not be using or testing your library's composer.json file at all. If you change a requirement in your library .json it will not flow through at all. So it has some big disadvantages, but does do what you want, which is to test your library implementation immediately with the least commands possible.
add your example implementation directly in your library tree (recommended)
Usually you just have src\ and tests\, but many have examples\ where you can find sample implementations. As you develop your application you can contribute to these example implementations. You can do this in a local git/svn repo, and you have the advantage of getting the lib's 'require', plus the namespace automatically. It is the best of all worlds. I recommend this method.
It seems most answers on this thread are not "in the know". I am new to Composer myself, but these answers are misleading. The question could simply be stated as: "How can I develop a composer package".
Yes, you could use a custom repository or upload an unfinished package and update it after every change. That neither is the correct solution or the answer to the question.
It doesn't help that Composer's official documentation doesn't state this upfront, but you can see the heading on the Libraries documentation page:
Every project is a package
This is very important to understand
composer.json:
The previously mentioned page goes on to state:
In order to make that package installable you need to give it a name. You do this by adding the name property in composer.json
{
"name": "acme/hello-world",
"require": {
"monolog/monolog": "1.0.*"
}
}
In this example so far, we have a required package, and now a name. Note the vendor/name format.
So now to autoloading our own files, which is documented on the Basic usage page.
{
"autoload": {
"psr-4": {"Acme\\": "src/"}
}
}
This will autoload the namespaced class files under the src/Acme directory.
On to the fun.
Install/Update
Install or update the package with the command:
composer update
or
php composer.phar update
This will download the required packages and create the autoload.php file
Our project structure should look simular to the following:
src
Acme
Foo.php
vendor
monolog
...
composer.json
Including
Now to test.
Include autoload.php
require_once 'path/to/project/vendor/autoload.php';
Assuming Foo.php looks like the following:
<?php
namespace Acme;
class Foo {
public static function bar(){
return 'baz';
}
}
?>
we can then call this from our script:
echo Acme\Foo::bar(); // baz
Please correct any misleading information I may have stated. This is what seems the be the solution to a popular question.
Maybe adding a custom repository will help you?
https://github.com/composer/composer/blob/master/doc/05-repositories.md
You can set up a local git repository with your library very easily.
Of course if you use composer to manage dependencies you should build your library someplace else and download it to vendor/ via composer coz this is the whole point i guess.
That's my flow of creating and developing a new Composer package locally:
Create a new repository for the package on GitHub (just an example)
Add it to Composer's database (packagist.org)
Add it to your main project via composer require. This is where you start wondering how can you apply hotfixes quickly
Clone it on your local machine somewhere, this is where you develop it
Now to test your local version, add a php require() statement where you load the class files in question. The autoloader won't load the one downloaded via composer but your local one.
When you're done hotfixing, delete/comment out the the require statement to revert back to using the composer version of the package.
Commit all changes, tag the commit and push to GitHub; hook fires to update Composer. Run composer update on your main project, the package gets updated to your local version.
This is still not ideal, but it gets the work done for small to medium packages.
To make developing more efficient I simply symlink the development repository into a directory that has already installed it.
For example, if /Code/project-1 requires a package that's in /Code/package-1, I:
Commit package-1 to GitHub (can even be private).
I then tell project-1 to install it using a custom repository (see other answers for the link to repository configuration).
Once it gets installed, I symlink /Code/project-1/vendor/developer/package-1 to /Code/package-1.
That way, when I make changes in /Code/package-1, it's immediately reflected in /Code/project-1.
My workflow does not completely answer the OP's question but may be helpful for others.
I like to develop a reusable package / lib in a real world project and I do not want to go through git / composer locally.
I also do not like to load the package differently locally compared to production (e.g. through a local require statement or local composer setting).
So what I do is simple: I add the package directly under the vendor directory, either directly or using a symlink.
drawbacks
When using composer update / install, your package may be overwritten. (so I tend to update or add dependencies one by one, during this time).
When not being careful, composer install on the production environment may install a different version. So keep pushing your package and version tags!!
Changing the package's dependencies and loading it in the parent project trough composer update, overwrites the package's folder
I have been using maven in JAVA and started using PHP Maven, recently I switched to composer.
My project is with Zend Framework 2 and the team only checks in the application code not anything on the vendor directory. This is done to avoid conflicts and not to have the libraries under SVN.
Now each time a developer sets his or her new environment, we observe that, the composer pulls the dependencies from internet. This takes quite a long time.
Is there any better idea/approach to make this faster or handling the project in different way to avoid this problem?
maven uses maven proxy servers which can cache the download and can be used in the network again, but do we have any solutions to handle problems like this?
Composer is a very young project, so there might be things missing which e.g. Maven can co without hassle.
You could set up your own Packagist server as described in the composer docs. I believe packagist has some caching options which can be used to store packages on the packagist server.
What you also could do is fork your dependencies and push them to a company-owned private repository. In your composer.json you would now only use this dependencies, making it faster to clone. Of course this would require you to maintain all the different dependencies (although this could be done with a script and a cronjob, pulling the data from the github repo and pushing it into your company owned).
I also believe composer has some proxy options, but I don't think these are meant to cache dependencies.
Last option would be to develop something like this, either as part of composer/packagist or as stand-alone.
In PHP there is an existing option for running a composer like repo locally and it's called Satis (it's actually provided by Composer) here: https://github.com/composer/satis
So you can run it locally on your server and point your composer to use that as a default composer repository and Satis makes sure that all installed packages and different versions are cached on disk as ZIP files so could be retrieved quicker compared to always downloading them from Internet.
You can do something like this:
{
"repositories": [
{
"type": "composer",
"url": "http://satis.example.org/"
}
],
"require": {
"company/package": "1.2.0",
"company/package2": "1.5.2",
"company/package3": "dev-master"
}
}
This also allows you to have private packages and libraries without exposing them on GitHub.
Another BIG advantage is when GitHub goes down for whatever reason you can still deploy as all of your dependancies are cached locally. This is assuming you haven't added new, non-existent packages to the release.