SitePoint Sponsor

User Tag List

Results 1 to 16 of 16
  1. #1
    SitePoint Zealot
    Join Date
    Jan 2011
    Location
    Portland
    Posts
    148
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Composer vs GitHub

    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?
    coming soon sitejuju.com my new development portfolio

  2. #2
    Avid Logophile silver trophy
    ParkinT's Avatar
    Join Date
    May 2006
    Location
    Central Florida
    Posts
    2,343
    Mentioned
    192 Post(s)
    Tagged
    4 Thread(s)
    Isn't Composer a Dependency Management system? 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?
    Don't be yourself. Be someone a little nicer. -Mignon McLaughlin, journalist and author (1913-1983)


    Git is for EVERYONE
    Literally, the best app for readers.
    Make Your P@ssw0rd Secure
    Leveraging SubDomains

  3. #3
    Always A Novice bronze trophy
    K. Wolfe's Avatar
    Join Date
    Nov 2003
    Location
    Columbus, OH
    Posts
    2,182
    Mentioned
    67 Post(s)
    Tagged
    2 Thread(s)
    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.

  4. #4
    SitePoint Zealot
    Join Date
    Jan 2011
    Location
    Portland
    Posts
    148
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by K. Wolfe View Post
    I got reemed a new one for not publishing my PHPErrorNet package to composer among other things when getting 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. Dependencies 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 dependencies as well. Composer does have some tools for "minimum version" handling and things like 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 tendency to re invent the wheel, 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?.
    coming soon sitejuju.com my new development portfolio

  5. #5
    Always A Novice bronze trophy
    K. Wolfe's Avatar
    Join Date
    Nov 2003
    Location
    Columbus, OH
    Posts
    2,182
    Mentioned
    67 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by jgetner View Post
    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.

  6. #6
    SitePoint Wizard silver trophybronze trophy asp_funda's Avatar
    Join Date
    Jun 2003
    Location
    ether
    Posts
    4,497
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by K. Wolfe View Post
    They re-invented git / svn.
    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.
    Our lives teach us who we are.
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Me - Photo Blog - Personal Blog - Dev Blog
    iG:Syntax Hiliter -- Colourize your code in WordPress!!

  7. #7
    Always A Novice bronze trophy
    K. Wolfe's Avatar
    Join Date
    Nov 2003
    Location
    Columbus, OH
    Posts
    2,182
    Mentioned
    67 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by asp_funda View Post
    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.
    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.

  8. #8
    SitePoint Wizard silver trophybronze trophy asp_funda's Avatar
    Join Date
    Jun 2003
    Location
    ether
    Posts
    4,497
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by K. Wolfe View Post
    Can't speak to that one since I don't have experience with svn or cvs.
    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.

    Quote Originally Posted by K. Wolfe View Post
    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.
    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):

    1. Create a Git repo for project.
    2. Package to install = A
    3. Hunt down the Git repo for Package to install & include it in your project as sub-module
    4. Does Package to install has any dependencies on other libraries/packages? If yes then continue else move to Step 7.
    5. Package to install = dependency
    6. Move to Step 3
    7. Has all packages been installed? If no then continue else move to Step 10.
    8. Package to install = next package to list (one from B, C & D)
    9. Move to Step 3
    10. 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:

    1. Create composer.json file
    2. Add all package names to composer.json
    3. Run >> composer install
    4. 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.
    Our lives teach us who we are.
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Me - Photo Blog - Personal Blog - Dev Blog
    iG:Syntax Hiliter -- Colourize your code in WordPress!!

  9. #9
    Always A Novice bronze trophy
    K. Wolfe's Avatar
    Join Date
    Nov 2003
    Location
    Columbus, OH
    Posts
    2,182
    Mentioned
    67 Post(s)
    Tagged
    2 Thread(s)
    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)

  10. #10
    Always A Novice bronze trophy
    K. Wolfe's Avatar
    Join Date
    Nov 2003
    Location
    Columbus, OH
    Posts
    2,182
    Mentioned
    67 Post(s)
    Tagged
    2 Thread(s)
    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
    Code:
    git submodule add /public/path/to/A lib/A
    Package C
    Code:
    git submodule add /public/path/to/A lib/A
    Project D
    Code:
    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:
    Code:
    git clone /path/to/D --recursive
    lib/B
    /A
    lib/C
    /A
    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?

  11. #11
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,313
    Mentioned
    19 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by K. Wolfe View Post
    Does anyone know if composer handles this?
    It does.

    Quote Originally Posted by K. Wolfe View Post
    If so what does that do for developers trying to do an include on these dependencies?
    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.
    "First make it work. Then make it better."

  12. #12
    Always A Novice bronze trophy
    K. Wolfe's Avatar
    Join Date
    Nov 2003
    Location
    Columbus, OH
    Posts
    2,182
    Mentioned
    67 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by Jeff Mott View Post
    Certainly Git submodules work just fine in a lot of cases. But Composer works better.
    Why have you come to this conclusion? Don't forget that sub modules of specific commits can be added, ensuring proper version is used.

    Quote Originally Posted by Jeff Mott View Post
    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 each account that each third-party package might autoload in a different way.
    Now that sounds useful.

  13. #13
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,313
    Mentioned
    19 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by K. Wolfe View Post
    Don't forget that sub modules of specific commits can be added, ensuring proper version is used.
    But what if...

    Quote Originally Posted by Jeff Mott
    ...packages B and C require slightly different versions of A. Maybe B uses A v2.1 and C uses A v2.2.
    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.
    "First make it work. Then make it better."

  14. #14
    Always A Novice bronze trophy
    K. Wolfe's Avatar
    Join Date
    Nov 2003
    Location
    Columbus, OH
    Posts
    2,182
    Mentioned
    67 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by Jeff Mott View Post
    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?

  15. #15
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,313
    Mentioned
    19 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by K. Wolfe View Post
    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:

    Code:
        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.
    "First make it work. Then make it better."

  16. #16
    SitePoint Guru
    Join Date
    Nov 2003
    Location
    Huntsville AL
    Posts
    695
    Mentioned
    4 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by K. Wolfe View Post
    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.
    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:
    PHP Code:
    {
        
    "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.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •