I don't think PEAR caught on as well because PHP has been largely associated with cheap hosting services that didn't really give you access to a console that would let you use PEAR to it's full extent. Then you have to add in the fact that PHP doesn't really have a solid package management philosophy in the first place.
I think it has more to do with the usual background of each language's programmers. Perl coders (especially Back In The Day) tended to disproportionately come to Perl from systems administration backgrounds; package management is something that sysadmins are used to worrying about, so they created a strong culture of package management in Perl early on. PHPers on the other hand tend disproportionally to come from web design/HTML+CSS backgrounds, which haven't exposed them to the problems that a good package manager is designed to solve. So package management in PHP has never been a priority.
The long lack of namespacing probably hurt the adopting of package management in PHP but also it seems like overkill. I use an occasional PEAR package, but I always just download the source and integrate it into the project that way. It seems like more work to go through a package manager especially since I work on multiple different operating systems. It might also help that PHP packages tend to have very few dependencies.
I think it may seem like more work, but without strong package management things like reinventing the kitchen sink & copy pasta from various unreliable sources becomes the norm. You could almost say that the comments in the PHP manual were relied on more often than PEAR.
Although package management can cause it's own problems like dependency hell or multiple packages that do the same thing but none of them do it well.
Comments
I don't think PEAR caught on as well because PHP has been largely associated with cheap hosting services that didn't really give you access to a console that would let you use PEAR to it's full extent. Then you have to add in the fact that PHP doesn't really have a solid package management philosophy in the first place.
I think it has more to do with the usual background of each language's programmers. Perl coders (especially Back In The Day) tended to disproportionately come to Perl from systems administration backgrounds; package management is something that sysadmins are used to worrying about, so they created a strong culture of package management in Perl early on. PHPers on the other hand tend disproportionally to come from web design/HTML+CSS backgrounds, which haven't exposed them to the problems that a good package manager is designed to solve. So package management in PHP has never been a priority.
The long lack of namespacing probably hurt the adopting of package management in PHP but also it seems like overkill. I use an occasional PEAR package, but I always just download the source and integrate it into the project that way. It seems like more work to go through a package manager especially since I work on multiple different operating systems. It might also help that PHP packages tend to have very few dependencies.
I think it may seem like more work, but without strong package management things like reinventing the kitchen sink & copy pasta from various unreliable sources becomes the norm. You could almost say that the comments in the PHP manual were relied on more often than PEAR.
Although package management can cause it's own problems like dependency hell or multiple packages that do the same thing but none of them do it well.