
Packages: The Way Forward for PHP - tombot
http://philsturgeon.co.uk/blog/2012/03/packages-the-way-forward-for-php#.T1XrZ9iu6YI.twitter
======
billybob
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
\- 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
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!)

~~~
darkstar999
> PHP is actually the hardest to find hosting for.

What? No. Do you have any proof of this? I have yet to come across a "normal"
shared/dedicated hosting service that doesn't support PHP. That is an insane
statement.

~~~
qixxiq
The reason for that is because your definition of normal hosting is shared.
(On a dedicated host you can run both PHP and Ruby; and they're roughly the
same in terms of getting set up.)

In terms of actually finding website hosting for an application?

Saying PHP is the hardest was likely an over-exagguration, but the market for
Heroku PaaS style hosting is growing massively and its Ruby runs on it very
easily.

Its not hard (at all) to find hosting for either, the only reason in my mind
PHP is harder is because of how beautifully PaaS works and that its free for
small applications (good luck finding a reasonable free php host -- I know
they exist but you'll have to dig through a whole lot of crud first)

~~~
kijin
The HN crowd is biased in favor of dedicated and virtual servers. But a very
large number of mom-and-pop web pages and small business sites are still
hosted on shared. That's what normal hosting means to a lot of people, and
it's a market that developers of popular tools (like Drupal and WordPress)
can't ignore.

------
dasil003
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
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.

------
Mikushi
Relevant XKCD : <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.

~~~
apinstein
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
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.

~~~
apinstein
All true. Care to help? I can make that happen!

~~~
jqueryin
I'd be willing to help. What are your thoughts on shifting gears towards Pyrus
(PEAR2) moving forward? I'd personally like to start with the freshest of the
fresh if I was going down the path of improving available package management
options in PHP. My thought would be to create a wrapper around Pyrus to
improve upon it.

<http://pear2.php.net/>

You can contact me via the email addy in my HN profile.

------
amishforkfight
> 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
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
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.

~~~
amishforkfight
What problems does it not solve that the unframework concept is supposed to
solve? I'm a but curious on what I'm missing out on, as I continuously feel
like it meets or exceeds all of my needs.

~~~
philsturgeon
An unframework is designed to give you a set of classes that you can use to
build your site. Sure, on that level it works but what about when you need
more?

At some point you need to have more classes, and where do they come from? One
team of developers cannot forever add in more and more classes, that would be
ridiculous.

If they allow other people to add in other classes they have an ever expanding
codebase. If they dont allow developers to add in other classes then you are
back to the original problem: where do I find new classes that will work with
my code.

By using a package management system you distribute the workload to people who
need a class, and so make it. People who have a vested interest (client
project, some web service they are making, whatever) are responsible for
working on a set of classes that really benefit them, like a payment library
that works with Recurly, Spreedly, whatever. That should be made buy one
developer, and a second developer could add in a new driver - instead of
building the whole damn thing from scratch.

That is the approach package managers take, and they are much more useful than
a one-man-army trying to build all the libraries.

Again if Flourish meets your requirements then great, but it certainly doesn't
meet all potential requirements of the whole PHP community, package managers
can with the "use whats there, build what isn't" approach.

------
acabal
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.

~~~
dhotson
Very interesting! Are you thinking something more along the lines of Python's
"batteries included" style standard library?

Also, it'd be great to move away from PHP's functions-in-global-namespace
style standard library, towards having a set of more well engineered core OO
libraries. The first examples that come to mind are: OO strings and
collections libraries. I'm thinking along the lines of Ruby's Enumerable.

~~~
philsturgeon
That is what PHP are doing, but slowly. When features are added they are often
as PECL or included as classes, and not as proceedural functions.

Moving forwards it seems like PHP is making the right calls, but backwards
compatibility is important to the project as PHP has more legacy code than any
other web language. That doesn't mean it's dead, it just means they can't say
"sod it, lets re-write everything overnight".

------
lux
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`"

------
jasonlotito
> 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
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>

------
kijin
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.

~~~
Seldaek
I'll only speak for Composer which is a new-ish PHP dependency manager,
because I'm the co-lead on the project.

System-wide packages are a massive pain, especially on shared hosts. That's
why we took the approach of installing everything local, much like virtualenv
or npm do. You get your dependencies for the project, in the project. Upload,
done. It comes with an autoloader to load classes and it all works with
relative paths, so moving it all around is no problem.

Obviously this only handles php libraries, not apt-get packages or whatever,
there are tons of great tools for managing system configuration, and we did
not set out to reinvent those. But php libraries can just be downloaded, a few
of them might depend on specific extensions but mostly if you have a recent-
ish PHP version stuff works on most shared hosts worth their name.

As for your point on adoption, I beg to differ. Symfony which is one of the
largest frameworks will use it in it's upcoming 2.1 release, I know of a few
other frameworks that are looking into it, many libraries are already made
available. Even major apps like Drupal have been looking into using it, not
for their plugins at first, only for their own dependencies, but once they
also discussed the adoption of it for plugins, and I know a few other CMSs
have looked at it for just that, because it's easy to wrap into a web frontend
to manage installation of dependencies from anywhere. I'd even argue you could
convert an entire ecosystem if you have it all in one controlled database
already, generating package metadata on the fly and installing from existing
sources, then giving the option to plugin authors to start requiring other
plugins and plain libraries instead of bundling everything in their code.

Composer is quite new and it's definitely not widely adopted yet, but things
are looking way brighter than you picture them. Given the ease of use of
publishing packages (basically you have to write one package definition like
in npm, and then for a new release you just have to git tag and push to
github), resistance from people should be pretty low. Please see docs on
<http://getcomposer.org/> if you are curious.

~~~
kijin
Thanks for the clarification. I guess I was a bit too negative in my first
comment.

I'm all for composer if it's going to make library management easier at any
level, either local or system-wide. Maybe if several well-known frameworks
agree to standardize on composer as their plug-in manager of choice, you may
even be able to obtain a de facto monopoly on PHP package management, and
that'll be a good thing for all of us. (I'd love to see some sanity in
WordPress plug-in management, too, but I guess that's a tall order.)

I just wanted to remind people that as long as you have to make concessions
for the current state of shared hosting, you will hit limits at one point or
another.

------
bergie
Something I wrote earlier on the subject:
[http://bergie.iki.fi/blog/composer_solves_the_php_code-
shari...](http://bergie.iki.fi/blog/composer_solves_the_php_code-
sharing_problem/)

HN discussion: <http://news.ycombinator.com/item?id=3184170>

------
downx3
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?

------
PaulHoule
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.

------
bithive123
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?

------
Jebus
502 Bad Gateway nginx/0.7.65

~~~
Supermighty
[http://webcache.googleusercontent.com/search?q=cache:http://...](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)

