9 ms·

Packages: The Way Forward for PHP

92 points by tombot 15y ago

Jebus 15y ago
502 Bad Gateway nginx/0.7.65
- Supermighty 15y ago
  http://webcache.googleusercontent.com/search?q=cache:http://philsturgeon.co.uk/blog/2012/03/packages-the-way-forward-for-php%23.T1XrZ9iu6YI.twitter&hl=en&client=ubuntu&hs=NGG&channel=fs&strip=1 http://webcache.googleusercontent.com/search?q=cache:http://...
- philsturgeon 15y ago
  Sorry about that, looks like I just DoS'ed myself. I was hosted on PHP Fog but just had to do a quick dash to Pagoda Box as their instance resizing doesn't happen quick enough. It should be up now, might need a dscache flush. What a mess.
acabal 15y ago
Packages and frameworks are great, but they exist because they solve problems that core PHP doesn't solve well. That's why there are so many different ORM layers and databases classes and templating frameworks. For example PHP gives you the nuts and bolts to put together a database class, but there still isn't a good, reusable library I can plug in to my next web app without having to mess with details like handling exceptions for update operations and so on. (PDO is close but not there yet.) Instead of centralizing a bunch of 3rd-party packages, PHP might better benefit by putting together a cleanly designed, optional, STL-like layer on top of the exposed nuts and bolts. Something like the powerful classes .NET provides. That way, a person could point to the official, well-documented, core-supported way of doing something like querying a database or subtracting two date objects instead of pointing to yet another "ultimate" PHP extension repository, maintained by who-knows. It might include things like rich database encapsulation, clean and obvious escaping of output for PHP's built-in template functionality, better datetime classes, and so on. SPL is kind-of-sort-of heading in that direction, but right now it's more for things like iterators and lists--still nuts and bolts. PHP is building some of the stuff I described into the core--there's an equivalent DateTime class now, though it's still in its infancy, and PDO is getting closer and closer to being a pluggable database object. But we've still got a long way to go. End the need for massive 3rd-party extension repositories and frameworks by building the necessary basics into the core. My dream would be to be able to have a PHP object library like the .NET ones. (Just the basics--DateTime, String, etc., not nightmares like DataGrid.) But I suspect PHP is too weighed down by its syntactical baggage and twisted history to be able to rise up to that dream.
- Supermighty 15y ago
  I always thought that was the goal of ZendFramework.
  - acabal 15y ago
    ZF is yet another framework, and a fairly complex-to-setup one as well. Problem is that when a newbie searches for "how to query mysql in php", they get 100 different tutorials doing it 100 different ways using the core functions. You won't find one using ZF unless you look for it. By the time a newbie is done digesting a mountain of tutorials, they realize that they need a framework, and they either build one of their own or turn to a 3rd party one. (And ZF doesn't seem to be the most popular one either, outside of the corporate environment.) Having a clean object library in the core would go a long way towards eliminating the very need for a framework like Zend, and give newbies a place to go for guaranteed development and documentation instead of being at the whim of a framework developer.
    - Supermighty 15y ago
      It's a little unfair of a comparison as .NET was released at the same time as C#. So C# never got the chance for little incorrect "how to query mssql in C#" articles. But I agree, whatever ZF original intention, not being simple and in-core is unfortunate.
      - verelo 15y ago
        I never found ZF difficult to setup, its a core part of a lot of the PHP work ive done...not saying it solves this problem but i am surprised people find it hard to use.
- philsturgeon 15y ago
  Primative Objects for all basic data types would be lovely, but that is another "Wishlist Feature" that may or may not happen at some point. The point of this article is not "What languages should PHP copy to get better", I am talking about "What PHP developers can do today with the available tools to fix things for tomorrow". PHP has everything it needs to move to a more package-based way of working, it just needs the community to take it up.
bergie 15y ago
Something I wrote earlier on the subject: http://bergie.iki.fi/blog/composer_solves_the_php_code-sharing_problem/ http://bergie.iki.fi/blog/composer_solves_the_php_code-shari... HN discussion: http://news.ycombinator.com/item?id=3184170 http://news.ycombinator.com/item?id=3184170
Mikushi 15y ago
Relevant XKCD : http://xkcd.com/927/ http://xkcd.com/927/ While I do agree that there is a need for a real packaging system for PHP, I don't think Composer/Packagist is the answer. Packaging is a real hard "exercise", I've dabbled with it, and it's certainly not an easy problem. Composer/Packagist is still not there yet and its ties to Symfony are "scaring" off developers (myself for example). If it wasn't for the outdated code, the bad peer review system, PEAR is the closest thing we have, as PHP developer, of a working packaging system. If only the PHP team would invest a bit of time to modernize it and make it relevant again, I'd give it a go for sure.
- philsturgeon 15y ago
  It's ties to Symfony are not that strong, and the more developers who get involved the more fair and even it will be. If Symfony are the only framework to use it then Packist is just going to be full of their code and not a lot else.
- apinstein 15y ago
  So then you love projects like Pearfarm.com (mine), pearhub.org, etc? These are simply "open" PEAR repos a la RubyGems. We use Pearfarm internally for all of our shared code, and it's super-easy to build and share packages. Frankly I don't understand why something like Pearfarm hasn't been widely adopted, since it is essentially the same as RubyGems which is a completely workable solution for the ruby community. I think people just don't understand that PEAR has 2 parts, the "installer" and the "official repo" and basically they write off anything related to PEAR. In any case I'd love to hear your thoughts on why the community doesn't rally around Pearfarm, Pearhub, etc since they are basically the solution you're looking for.
  - jqueryin 15y ago
    The site needs a revamp but is there in concept. It'd only take about a days worth of time to give the site a facelift. You're missing basic things like completion of the additional instructions page.
    - 15y ago
jasonlotito 15y ago
> The nail in the coffin for me with PEAR is one of the biggest bug bears of the Gem system: system-wide installation. If I want to use a specific package, which requires a newer version of an already installed package, then I have to update it on my whole installation. That means an application I have not touched in weeks might break next time I try loading it on my local box. WAT? No, you don't. You can have a system wide installation, but you can also install local copies that are just used for certain apps, and it can be managed using pear.
- apinstein 15y ago
  Correct. We have been using sandboxed PEAR repos as part of our deployment for a long time. One of our devs even wrote a PEAR app called "comice" that allows you to easily create a sandbox and use it from the CLI. https://github.com/ardell/comice https://github.com/ardell/comice
amishforkfight 15y ago
> Thats idea is lovely and all but Flourish never made it out of BETA after years of development. I'm happy to see Flourish getting some notice, even though there doesn't seem to be a lot of love for it with the small mention. I'm happy Flourish user for well over a year now, and I feel as if Flourish's BETA tag is akin to Google's BETA tag. I honestly haven't run across a single issue with the library that would discourage me from using it in a production environment. It's an unframework, it doesn't force MVC, but you know what? I don't need MVC for 90% of what I do. What I need to do is validate form input, accept a few file uploads, log that to a DB, kick off a few internal emails, and provide user feedback. I think that some day I'll dig into Code Igniter, but as the only web developer/designer in the marketing department for a small company a tool that lets me stay agile and do less than conventional setups, as well as easily integrate into existing environments has been a godsend for me. It smooths out a lot of PHP's weird quirks, comes pre-baked with an amazing focus on security (oh thank god for your passion for security, @wbond), and in general just helps me get my job done. Oh, and when people ask me what framework I use, I say "Flourish, it's like jQuery for PHP". /fanboy edit: One downside to Flourish is that I'm almost useless without it. What do I use to sanitize a POST variable again? How do I unescape before output? I've gotten so used to the Flourish classes I spend more time on Google than coding when I don't have access to it.
- lrobb 15y ago
  Another fan of Flourish. From the site: Please note that Flourish has undergone a good deal of real-world testing, and can generally be considered production ready.
  - philsturgeon 15y ago
    I have of course seen that, but it doesn't fill potential users with much hope when they see it. I'm sure it's lovely, but in the scope of the article it is just not solving the problem unframeworks set out to solve. It has also failed to keep up with progress, for example: fDate is basically the same as the recent DateTime object in PHP, as are many other classes now.
PaulHoule 15y ago
One big problem with PEAR is that PEAR hasn't tracked changes in the PHP language. You can't expect that packages from PEAR will work in a recent version of PHP if you don't set the warning levels very low and enable the backwards compatibility settings that you really shouldn't.
lux 15y ago
I definitely agree that Composer/Packagist are the way forward for PHP, and they are gaining momentum and support. What always helps is solid documentation, which seems to be coming along. There's now a site up at getcomposer.org with info about the Composer file schema and usage, which will really help frameworks looking to adopt it. It appears frameworks can implement their own package type handlers, and specify alternate target directories, which goes a long way towards making it possible to integrate it with their own package formats. I can see in a year or two's time the standard across PHP apps and frameworks becoming "add this add-on to your composer.json and install via `composer.phar install`"
billybob 15y ago
This is going to sound like I'm trolling, but: why not just use Ruby? Like many Ruby developers, I left PHP because I saw the kind of stagnation the author describes at the beginning of this article. I saw lots of good ideas originating and flourishing in the Ruby world, and sometimes trickling back to PHP. I saw a more well-thought-out language that seemed worthy of all that attention. So I hopped. The libraries and library management tools and frameworks available to me now are awesome. Ruby itself is getting faster all the time. Is there really any reason left to stick with PHP other than inertia? (I don't mean that dismissively; if you have a massive existing code base, that's real inertia and changing would be a tall order.) You can substitute Python or Node or whatever for Ruby here, but my point is: why fight the uphill battle to bring good tools to a language when other languages already have them?
- Mikushi 15y ago
  - PHP is the easiest to find hosting for, to setup and to learn. - PHP is still the best at generating web pages. - PHP offers all the tools needed to build strong applications (PHPUnit, xDebug, XHProf, ...) - PHP is not as bad as people like to say. And I could go on for hours on why I (and others probably) stick to PHP.
  - qixxiq 15y ago
    Unfortunately the common argument is not always true. To be honest at this point in time I would say PHP is actually the hardest to find hosting for. I'm a long time PHP developer and just recently tried Heroku out -- its like magic. Best for generating web pages is a meaningless metric, and... To be honest my main issue with PHP relates to the defense that "PHP is not as bad as people like to say.". I mean, really - its true. PHP5 is significantly better language than the previous versions, and people always over-exaggerate how bad it is. The problem is that PHP is not a good language. Whenever I develop in Python/Ruby I actually enjoy the 'feel' of the language, and I'm often impressed by the power it has to do really complicated things in simple concise instructions. Most of the time when I'm working with PHP the feeling is very different. I can perform the same operations but generally theres far more cruft, and a couple manual lookups to see why functions behave differently when hashes ("arrays") have numeric indices (I'm looking at you array_merge!)
dasil003 15y ago
You could dedicate your life to improving package management in PHP and still never approach the quality of even RubyGems, let alone CPAN. Inertia is just too much to fight against when you have a massively popular language with an ad-hoc design that has accreted over a decade. More power to anyone with a vision and a goal, but I'll personally leave PHP to its strength as batteries-included templating language.
- philsturgeon 15y ago
  We aren't in a competition against Gems or CPAN, in what world does that suggestion even make sense? People use PHP and a package manager is needed to stop people constantly rewriting the same PHP. That means a package manager is required (we have a good one now) and support is required to take it forward (hence this post). When will people stop the "RUBY DID IT" mentality and learn to get on with what needs to be done? 1. Build stuff. 2. Sell stuff. 3. Learn to make stuff faster.
kijin 15y ago
I think the #1 barrier to the use of packaging systems in PHP is the fact that, even nowadays, the lion's share of PHP apps are hosted on shared hosting. In shared hosting, you don't have the ability to add system-wide packages. Good luck asking the hosting company to add arbitrary packages in any language. You might not even have a proper shell. There are a billion security issues to take into consideration when you try to access anything outside of your home directory. There's no standardization whatsoever about where to put files that don't need to be publicly accessible, though you could argue that cPanel's monopoly offers a quasi-standard. It shouldn't come as a surprise that just-upload-the-whole-damn-thing-yourself is the default method of deploying PHP packages and libraries. You could come up with the best packaging system to use on your own server, but you won't be able to get any popular apps and frameworks to adopt it as long as those apps and frameworks need to support shared hosting customers. Shared hosting needs to be fixed before you can have a packaging system for PHP that is as powerful as npm, gem, and easy_install.
- yuri41 15y ago
  I don't think that shared hosting needs to be fixed before you can benefit from a good package manager. Composer and Pyrus both are able to install packages local to the project. So just grab the dependencies before and then upload the "damn thing" to the server to deploy and this will work on every shared host out there.
  - kijin 15y ago
    Sure, you can get part of the benefit even if you're on shared hosting. (Off-topic but related example: I use git to manage projects locally even if they are going to be deployed to a server that doesn't support git. Last week I finally moved a small-business client to a git-enabled host, and it was such a relief.) But it's only part of the benefit. A good packaging system, for example, will track your PHP version and extensions and make appropriate adjustments. But what if your host uses a slightly different version of PHP with a slightly different list of extensions? At best, the packaging system makes adjustments again, and you cross your fingers hoping that nothing breaks. At worst, everything breaks because your host uses the wrong version of GD or whatever. Every shared host that supports Ruby gets mired in requests for and complaints about specific versions of gems they've installed. I don't think it will be any different for PHP.
bithive123 15y ago
Seven paragraphs about how every attempt at code reuse in PHP ends in failure followed by an exhortation for everyone to gather round for another go? Are we sure this isn't satire?
downx3 15y ago
What is broken here is surely package management in general? I'd like to use one tool. If you don't want files system wide - then perhaps that should be an option in the package management system. It would seem silly and wasteful to have dozens and dozens of the same packages languishing on the same computer. So part of me thinks this needs to be handled at the filesystem level. Or there should be a way for package managers to speak to each other. How about throwing something like apt-get and dpkg out and replacing it with something better - that can handle Gems, Python libraries, etc?

92 points by tombot 15y ago

Jebus 15y ago

502 Bad Gateway nginx/0.7.65

Supermighty 15y ago
http://webcache.googleusercontent.com/search?q=cache:http://philsturgeon.co.uk/blog/2012/03/packages-the-way-forward-for-php%23.T1XrZ9iu6YI.twitter&hl=en&client=ubuntu&hs=NGG&channel=fs&strip=1 http://webcache.googleusercontent.com/search?q=cache:http://...
philsturgeon 15y ago
Sorry about that, looks like I just DoS'ed myself. I was hosted on PHP Fog but just had to do a quick dash to Pagoda Box as their instance resizing doesn't happen quick enough. It should be up now, might need a dscache flush. What a mess.

acabal 15y ago

Packages and frameworks are great, but they exist because they solve problems that core PHP doesn't solve well. That's why there are so many different ORM layers and databases classes and templating frameworks. For example PHP gives you the nuts and bolts to put together a database class, but there still isn't a good, reusable library I can plug in to my next web app without having to mess with details like handling exceptions for update operations and so on. (PDO is close but not there yet.) Instead of centralizing a bunch of 3rd-party packages, PHP might better benefit by putting together a cleanly designed, optional, STL-like layer on top of the exposed nuts and bolts. Something like the powerful classes .NET provides. That way, a person could point to the official, well-documented, core-supported way of doing something like querying a database or subtracting two date objects instead of pointing to yet another "ultimate" PHP extension repository, maintained by who-knows. It might include things like rich database encapsulation, clean and obvious escaping of output for PHP's built-in template functionality, better datetime classes, and so on. SPL is kind-of-sort-of heading in that direction, but right now it's more for things like iterators and lists--still nuts and bolts. PHP is building some of the stuff I described into the core--there's an equivalent DateTime class now, though it's still in its infancy, and PDO is getting closer and closer to being a pluggable database object. But we've still got a long way to go. End the need for massive 3rd-party extension repositories and frameworks by building the necessary basics into the core. My dream would be to be able to have a PHP object library like the .NET ones. (Just the basics--DateTime, String, etc., not nightmares like DataGrid.) But I suspect PHP is too weighed down by its syntactical baggage and twisted history to be able to rise up to that dream.

Supermighty 15y ago
I always thought that was the goal of ZendFramework.
- acabal 15y ago
  ZF is yet another framework, and a fairly complex-to-setup one as well. Problem is that when a newbie searches for "how to query mysql in php", they get 100 different tutorials doing it 100 different ways using the core functions. You won't find one using ZF unless you look for it. By the time a newbie is done digesting a mountain of tutorials, they realize that they need a framework, and they either build one of their own or turn to a 3rd party one. (And ZF doesn't seem to be the most popular one either, outside of the corporate environment.) Having a clean object library in the core would go a long way towards eliminating the very need for a framework like Zend, and give newbies a place to go for guaranteed development and documentation instead of being at the whim of a framework developer.
  - Supermighty 15y ago
    It's a little unfair of a comparison as .NET was released at the same time as C#. So C# never got the chance for little incorrect "how to query mssql in C#" articles. But I agree, whatever ZF original intention, not being simple and in-core is unfortunate.
    - verelo 15y ago
      I never found ZF difficult to setup, its a core part of a lot of the PHP work ive done...not saying it solves this problem but i am surprised people find it hard to use.
philsturgeon 15y ago
Primative Objects for all basic data types would be lovely, but that is another "Wishlist Feature" that may or may not happen at some point. The point of this article is not "What languages should PHP copy to get better", I am talking about "What PHP developers can do today with the available tools to fix things for tomorrow". PHP has everything it needs to move to a more package-based way of working, it just needs the community to take it up.

bergie 15y ago

Something I wrote earlier on the subject: http://bergie.iki.fi/blog/composer_solves_the_php_code-sharing_problem/ http://bergie.iki.fi/blog/composer_solves_the_php_code-shari... HN discussion: http://news.ycombinator.com/item?id=3184170 http://news.ycombinator.com/item?id=3184170

Mikushi 15y ago

Relevant XKCD : http://xkcd.com/927/ http://xkcd.com/927/ While I do agree that there is a need for a real packaging system for PHP, I don't think Composer/Packagist is the answer. Packaging is a real hard "exercise", I've dabbled with it, and it's certainly not an easy problem. Composer/Packagist is still not there yet and its ties to Symfony are "scaring" off developers (myself for example). If it wasn't for the outdated code, the bad peer review system, PEAR is the closest thing we have, as PHP developer, of a working packaging system. If only the PHP team would invest a bit of time to modernize it and make it relevant again, I'd give it a go for sure.

philsturgeon 15y ago
It's ties to Symfony are not that strong, and the more developers who get involved the more fair and even it will be. If Symfony are the only framework to use it then Packist is just going to be full of their code and not a lot else.
apinstein 15y ago
So then you love projects like Pearfarm.com (mine), pearhub.org, etc? These are simply "open" PEAR repos a la RubyGems. We use Pearfarm internally for all of our shared code, and it's super-easy to build and share packages. Frankly I don't understand why something like Pearfarm hasn't been widely adopted, since it is essentially the same as RubyGems which is a completely workable solution for the ruby community. I think people just don't understand that PEAR has 2 parts, the "installer" and the "official repo" and basically they write off anything related to PEAR. In any case I'd love to hear your thoughts on why the community doesn't rally around Pearfarm, Pearhub, etc since they are basically the solution you're looking for.
- jqueryin 15y ago
  The site needs a revamp but is there in concept. It'd only take about a days worth of time to give the site a facelift. You're missing basic things like completion of the additional instructions page.
  - 15y ago

jasonlotito 15y ago

> The nail in the coffin for me with PEAR is one of the biggest bug bears of the Gem system: system-wide installation. If I want to use a specific package, which requires a newer version of an already installed package, then I have to update it on my whole installation. That means an application I have not touched in weeks might break next time I try loading it on my local box. WAT? No, you don't. You can have a system wide installation, but you can also install local copies that are just used for certain apps, and it can be managed using pear.

apinstein 15y ago
Correct. We have been using sandboxed PEAR repos as part of our deployment for a long time. One of our devs even wrote a PEAR app called "comice" that allows you to easily create a sandbox and use it from the CLI. https://github.com/ardell/comice https://github.com/ardell/comice

amishforkfight 15y ago

> Thats idea is lovely and all but Flourish never made it out of BETA after years of development. I'm happy to see Flourish getting some notice, even though there doesn't seem to be a lot of love for it with the small mention. I'm happy Flourish user for well over a year now, and I feel as if Flourish's BETA tag is akin to Google's BETA tag. I honestly haven't run across a single issue with the library that would discourage me from using it in a production environment. It's an unframework, it doesn't force MVC, but you know what? I don't need MVC for 90% of what I do. What I need to do is validate form input, accept a few file uploads, log that to a DB, kick off a few internal emails, and provide user feedback. I think that some day I'll dig into Code Igniter, but as the only web developer/designer in the marketing department for a small company a tool that lets me stay agile and do less than conventional setups, as well as easily integrate into existing environments has been a godsend for me. It smooths out a lot of PHP's weird quirks, comes pre-baked with an amazing focus on security (oh thank god for your passion for security, @wbond), and in general just helps me get my job done. Oh, and when people ask me what framework I use, I say "Flourish, it's like jQuery for PHP". /fanboy edit: One downside to Flourish is that I'm almost useless without it. What do I use to sanitize a POST variable again? How do I unescape before output? I've gotten so used to the Flourish classes I spend more time on Google than coding when I don't have access to it.

lrobb 15y ago
Another fan of Flourish. From the site: Please note that Flourish has undergone a good deal of real-world testing, and can generally be considered production ready.
- philsturgeon 15y ago
  I have of course seen that, but it doesn't fill potential users with much hope when they see it. I'm sure it's lovely, but in the scope of the article it is just not solving the problem unframeworks set out to solve. It has also failed to keep up with progress, for example: fDate is basically the same as the recent DateTime object in PHP, as are many other classes now.

PaulHoule 15y ago

One big problem with PEAR is that PEAR hasn't tracked changes in the PHP language. You can't expect that packages from PEAR will work in a recent version of PHP if you don't set the warning levels very low and enable the backwards compatibility settings that you really shouldn't.

lux 15y ago

I definitely agree that Composer/Packagist are the way forward for PHP, and they are gaining momentum and support. What always helps is solid documentation, which seems to be coming along. There's now a site up at getcomposer.org with info about the Composer file schema and usage, which will really help frameworks looking to adopt it. It appears frameworks can implement their own package type handlers, and specify alternate target directories, which goes a long way towards making it possible to integrate it with their own package formats. I can see in a year or two's time the standard across PHP apps and frameworks becoming "add this add-on to your composer.json and install via `composer.phar install`"

billybob 15y ago

This is going to sound like I'm trolling, but: why not just use Ruby? Like many Ruby developers, I left PHP because I saw the kind of stagnation the author describes at the beginning of this article. I saw lots of good ideas originating and flourishing in the Ruby world, and sometimes trickling back to PHP. I saw a more well-thought-out language that seemed worthy of all that attention. So I hopped. The libraries and library management tools and frameworks available to me now are awesome. Ruby itself is getting faster all the time. Is there really any reason left to stick with PHP other than inertia? (I don't mean that dismissively; if you have a massive existing code base, that's real inertia and changing would be a tall order.) You can substitute Python or Node or whatever for Ruby here, but my point is: why fight the uphill battle to bring good tools to a language when other languages already have them?

Mikushi 15y ago
- PHP is the easiest to find hosting for, to setup and to learn. - PHP is still the best at generating web pages. - PHP offers all the tools needed to build strong applications (PHPUnit, xDebug, XHProf, ...) - PHP is not as bad as people like to say. And I could go on for hours on why I (and others probably) stick to PHP.
- qixxiq 15y ago
  Unfortunately the common argument is not always true. To be honest at this point in time I would say PHP is actually the hardest to find hosting for. I'm a long time PHP developer and just recently tried Heroku out -- its like magic. Best for generating web pages is a meaningless metric, and... To be honest my main issue with PHP relates to the defense that "PHP is not as bad as people like to say.". I mean, really - its true. PHP5 is significantly better language than the previous versions, and people always over-exaggerate how bad it is. The problem is that PHP is not a good language. Whenever I develop in Python/Ruby I actually enjoy the 'feel' of the language, and I'm often impressed by the power it has to do really complicated things in simple concise instructions. Most of the time when I'm working with PHP the feeling is very different. I can perform the same operations but generally theres far more cruft, and a couple manual lookups to see why functions behave differently when hashes ("arrays") have numeric indices (I'm looking at you array_merge!)

dasil003 15y ago

You could dedicate your life to improving package management in PHP and still never approach the quality of even RubyGems, let alone CPAN. Inertia is just too much to fight against when you have a massively popular language with an ad-hoc design that has accreted over a decade. More power to anyone with a vision and a goal, but I'll personally leave PHP to its strength as batteries-included templating language.

philsturgeon 15y ago
We aren't in a competition against Gems or CPAN, in what world does that suggestion even make sense? People use PHP and a package manager is needed to stop people constantly rewriting the same PHP. That means a package manager is required (we have a good one now) and support is required to take it forward (hence this post). When will people stop the "RUBY DID IT" mentality and learn to get on with what needs to be done? 1. Build stuff. 2. Sell stuff. 3. Learn to make stuff faster.

kijin 15y ago

I think the #1 barrier to the use of packaging systems in PHP is the fact that, even nowadays, the lion's share of PHP apps are hosted on shared hosting. In shared hosting, you don't have the ability to add system-wide packages. Good luck asking the hosting company to add arbitrary packages in any language. You might not even have a proper shell. There are a billion security issues to take into consideration when you try to access anything outside of your home directory. There's no standardization whatsoever about where to put files that don't need to be publicly accessible, though you could argue that cPanel's monopoly offers a quasi-standard. It shouldn't come as a surprise that just-upload-the-whole-damn-thing-yourself is the default method of deploying PHP packages and libraries. You could come up with the best packaging system to use on your own server, but you won't be able to get any popular apps and frameworks to adopt it as long as those apps and frameworks need to support shared hosting customers. Shared hosting needs to be fixed before you can have a packaging system for PHP that is as powerful as npm, gem, and easy_install.

yuri41 15y ago
I don't think that shared hosting needs to be fixed before you can benefit from a good package manager. Composer and Pyrus both are able to install packages local to the project. So just grab the dependencies before and then upload the "damn thing" to the server to deploy and this will work on every shared host out there.
- kijin 15y ago
  Sure, you can get part of the benefit even if you're on shared hosting. (Off-topic but related example: I use git to manage projects locally even if they are going to be deployed to a server that doesn't support git. Last week I finally moved a small-business client to a git-enabled host, and it was such a relief.) But it's only part of the benefit. A good packaging system, for example, will track your PHP version and extensions and make appropriate adjustments. But what if your host uses a slightly different version of PHP with a slightly different list of extensions? At best, the packaging system makes adjustments again, and you cross your fingers hoping that nothing breaks. At worst, everything breaks because your host uses the wrong version of GD or whatever. Every shared host that supports Ruby gets mired in requests for and complaints about specific versions of gems they've installed. I don't think it will be any different for PHP.

bithive123 15y ago

Seven paragraphs about how every attempt at code reuse in PHP ends in failure followed by an exhortation for everyone to gather round for another go? Are we sure this isn't satire?

downx3 15y ago

What is broken here is surely package management in general? I'd like to use one tool. If you don't want files system wide - then perhaps that should be an option in the package management system. It would seem silly and wasteful to have dozens and dozens of the same packages languishing on the same computer. So part of me thinks this needs to be handled at the filesystem level. Or there should be a way for package managers to speak to each other. How about throwing something like apt-get and dpkg out and replacing it with something better - that can handle Gems, Python libraries, etc?