So I have been a php programmer for some years now and i do not understand why we are collectively using Composer when there is already tools that can do the exact same thing such as github/GIT. Your thoughts?
Isn’t Composer a Dependency Management system? [URL=“https://learnable.com/books/git-fundamentals”]Git is Source Control; something very much different.
Regardless, there is an advantage to having many tools from which to choose. We all have preferences and different workflows.
Is there something, in particular, about Composer that you don’t like?
I got reemed a new one for not publishing my PHPErrorNet package to composer amoung other things when gettings some reviews on it, even though I have it on github. To jgetners point, pretty much the entire functionality of composer is on github and more. Dependancies can be handled in git with sub repositories, which I prefer over composer anyday. When installing, you would then just use --recursive option to pull in your dependancies as well. Composer does have some tools for “minimum version” handling and things llike that. IMO, its nice, but we don’t need it as long as we are using something such as git. I find it amusing that the PHP community has clung on to composer so hard in comparison to git, which most other developers in other languages use as the norm. More amusing that in the description of what composer’s purpose is “PHP developers have the tendancy to re invent the weel, so we created this” blah, blah. They re-invented git / svn.
k.wolfe pretty much summed that up.
But it also seems the php community is torn in half and on one side we have the “open source” community that writes some really great software/code but force things upon you like composer. It’s used in many of the popular frameworks where you have to clone the framework then you have to also do some composer calls?
This is a bit redundant and just really not necessary so why is the open source community forcing this one when the professional community is rejecting it?.
I did state that composer has a feature for minimum version checking, whcih git or svn doesn’t really handle. There may be other featues that git doesn’t have that I am mot aware of as well.
If that is to go by then why use Git at all? Why not just stick to Subversion? Or even then, why Subversion either? Everyone should’ve stuck with CVS, it was doing the job pretty much. 
Composer is not a source control management system; Git, Subversion, etc. are. Sure you can use Git or SVN for rudimentary stuff that Composer does but thats like driving an airplane to supermarket to get groceries, sure you can drive it on road but why the heck would you do it? Even when you make your package available to Composer, you create a manifest file in which you put in the source URL. Packagist just hosts a manifest file for packages with version and dependency info etc in it. So you would still be putting up your code on Github or wherever you host your public code and referencing that URL in your package manifest. Composer will grab the source from that URL when anyone installs your package using it.
Git, SVN etc are for keeping track of versions of your code, not for dependency management. One cool thing about Composer is that you can share a JSON file (composer.json) with anyone which includes what packages need to be installed. The person you share it with just needs to run “composer install” in the dir in which that JSON file is and all the stuff gets installed along with any dependencies. No need for Git or SVN etc to be present on that machine.
Can’t speak to that one since I don’t have experience with svn or cvs.
What does composer do differently than a git clone x --recursive with submodules? No need for composer to be present on that machine. I know of one feature that composer has and that is minimum version checking, but then I can pick up a feature using git and that is the ability to add a submodule to a specific version if you wanted to.
I have thats why I said that they both did their job well. Subversion came because CVS had some shortcomings, so SVN was more like re-imagining how to accomplish a task rather than re-inventing the wheel. Then SVN had its shortcomings as well, enter Git & Mercurial, a re-imagination on how to do the job in a better way.
But comparing Composer with Git & its ilk is like comparing apples to oranges, both were made to accomplish different goals.
Seems like you didn’t read my last post. Git or SVN etc are things you need to install to be able to use them, Composer is just a PHP Archive (a PHAR file just like Java archive is a JAR file) containing a bunch of PHP scripts. No need to install anything.
Lets consider an example. Say we need to install some packages in our app - A, B, C & D.
Lets do it your way (using Git for what its not):
- Create a Git repo for project.
- Package to install = A
- Hunt down the Git repo for Package to install & include it in your project as sub-module
- Does Package to install has any dependencies on other libraries/packages? If yes then continue else move to Step 7.
- Package to install = dependency
- Move to Step 3
- Has all packages been installed? If no then continue else move to Step 10.
- Package to install = next package to list (one from B, C & D)
- Move to Step 3
- You’re all done, congratulations. But if any of your included packages adds another dependency in future, then good luck, you’re gonna need it.
Now lets do it Composer way:
- Create composer.json file
- Add all package names to composer.json
- Run >> composer install
- You’re done, congratulations. If any of the included packages adds or removes any dependencies in future then let them do it, you don’t have to worry at all.
If this doesn’t show the difference between Composer & using Git as something it is not then I don’t know what will.
This discussion is now just going to get out of context & off topic, arguments for arguments sake, something I definitely don’t have any intention to indulge in. So, each to his/her own.
Your viewing steps for git as a developer and composer as a client. Those steps in git still exist in composer as a developer. You are relying on previous authors to supply what their projects dependencies are. In the end, as the client, both still can come down to a one line clone of the project (that also pulls dependencies)
For people interested: http://git-scm.com/docs/git-submodule
One downside that can be argued here is that a dependency will then be stored within the directory of the project being worked on, making it inconvenient to be used with other projects. Example excluding commits and pushes:
Package B depends on package A. Project C is a separate package from B, but also depends on A. Project D depends on B and C (in turn also A)
Package B
git submodule add /public/path/to/A lib/A
Package C
git submodule add /public/path/to/A lib/A
Project D
git submodule add /public/path/to/C lib/C
git submodule add /public/path/to/B lib/B
Project D would then have a structure as follows:
git clone /path/to/D --recursive
lib/B[INDENT]/A
[/INDENT]
lib/C[INDENT]/A
[/INDENT]
Package A is now duplicated. Does anyone know if composer handles this? If so what does that do for developers trying to do an include on these dependencies?
It does.
I imagine it would prevent loading conflicts. If manually loading, and both packages B and C try to require their own copy of A, then you’ll get class already defined errors. Or if autoloading, then the two copies of A may both be registered. It gets even more complicated if packages B and C require slightly different versions of A. Maybe B uses A v2.1 and C uses A v2.2. This can result in a hard to find bug in your project D. Composer, on the other hand, will resolve common dependencies, and it will throw an informative error if there are conflicts.
Certainly Git submodules work just fine in a lot of cases. But Composer works better.
Some other nice nuggets: With Composer, the third-party library isn’t required to be a git repo. It could be SVN, or a ZIP, or a PEAR package, among others. It will also generate the autoload file for you, taking into account that each third-party package might autoload in a different way.
Why have you come to this conclusion? Don’t forget that sub modules of specific commits can be added, ensuring proper version is used.
Now that sounds useful.
But what if…
Certainly both B and C can ensure their submodule points to the proper version for their library, but at runtime, only one of those two copies of A can be loaded.
Point well taken. From the sounds of it, Composer will throw an error on clone?
Indeed it will. Before it even starts downloading or cloning any repositories, it will throw an error saying something along the lines of “dependencies cannot be resolved into an installable package.” As opposed to git submodules, where this sort of problem will manifest itself at runtime in the form of some obscure bug.
Plus, even in more straightforward cases, where library A depends on library B, which depends on C, which depends on D, etc., submodules would yield a directory structure like this:
doctrine-orm/
vendor/
symfony-console/
vendor/
symfony-event-dispatcher/
vendor/
symfony-dependency-injection/
vendor/
symfony-config/
vendor/
symfony-filesystem/
The more complex the dependency tree becomes, the less useful submodules are.
That was certainly unfortunate. Composer is quite capable of loading packages directly from github without requiring any publishing. A simple composer.json file is all you would need to add. Something like:
{
"name": "cerad/cerad",
"type": "symfony-bundles",
"description": "Cerad Libraries",
"keywords": ["security"],
"homepage": "https://github.com/cerad/cerad2.git",
"license": "MIT",
"authors": [
{
"name": "Art Hundiak",
"email": "arthundiak@gmail.com"
}
],
"require": {
"php": ">=5.3.3"
},
"autoload": {
"psr-0": {
"Cerad": "src"
}
},
"target-dir": ""
}
And even that could be simplified.