

Composer: NPM-like package management for PHP - bergie
http://bergie.iki.fi/blog/composer_solves_the_php_code-sharing_problem/

======
apinstein
I am one of the guys behind <http://pearfarm.org>. I mention it just to show
I've thought a lot about this problem.

What's interesting is that we all know something like this _needs_ to happen
for the PHP community, but the community isn't stepping up and rallying around
one. Maybe being sucked into the Symfony world will help it get traction, but
I am not sure, only because history has not been on the side of progress of
this issue in the PHP community.

PEARFarm hasn't caught on too much (though we use it extensively in-house).

Composer works almost identically to <http://pearhub.org>, and didn't catch
on, either.

Beyond that, there have been more (see phark, etc).=

As for feedback on your idea, my concerns are: 1) Support for legacy PEAR
packages doesn't seem to exist. There is a lot of code out there that people
already depend on. 2) PHP 5.3 only, while it is the future, still knocks down
the addressable market to maybe 1/4 of the PHP world. 3) Does your packaging
system support installation of executables? 4) Is there a bundler-style
solution? I need to be able to easily install all dependencies in a sandbox.
Committing an enormous vendor/ dir is an absurd practice. 5) Does Composer
allow the package to not include all files in the git repo?

That said, I would _love_ for there to be a standard, widely-used, useful,
easy & practical way to manifest dependencies and install them into a sandbox.
I waste way too much time managing this on my own.

~~~
Seldaek
1) It does support PEAR, it's listed on <http://packagist.org/about-composer>

2) PHP5.3, well, so be it. The people stuck in the past are usually not the
ones willing to take the plunge into such solution anyway. They can join us
when they are ready.

3) Not yet, but we do have some plans for that.

4) You shouldn't commit your vendor dir, you should commit the composer.lock
file, which allows anyone to re-install exactly the same version of the
dependencies anywhere. And yes this is similar to Bundler as far as I
understand it.

5) We also have plans for that, see
<https://github.com/composer/composer/issues/57> \- but this depends on other
features that we need to finish first.

~~~
apinstein
1) Ah ok, didn't see that.

Do you PEAR-install PEAR packages? It's important for when there are
executables. We wrote another project called comice to make it easy to create
PEAR sandboxes and work with them: <https://github.com/ardell/comice>

2) We will move to 5.3 ourselves soon, I am just telling you the reality. PHP
5.3 broke some BC stuff, making it risky to migrate. I think that's slowed
adoption a lot.

3) Not a huge problem that it doesn't install executables, so long as you
support legacy PEAR installs with executables (see #1).

4) Cool, I will have to look into that.

------
josegonzalez
I've looked through this code - I have several such needs for packaging PHP
dependencies - and have decided against using it for several reasons:

\- Like most code coming from the Symfony community, it is built Java-style.
Not a bad thing, but many things, such as dependency checking or version
management, can be done in much simpler ways with less code

\- PHP 5.3 only. Thanks, but no thanks. I know everyone is in a rush to
promote 5.3, but I feel as though it can be done in such a way as to
gracefully degrade and support older versions of PHP quite easily.

\- Has dependencies on Symfony projects. That is a great way to have other
frameworks adopt your tools! I'm sure this is going away, especially if they
want framework-wide support.

That said, I'm jealous. I've been working on something similar for a few
months in private and this is already on Github. If they can iron out my above
issues, I'll be happy.

~~~
bergie
Why would it matter how Composer itself is built? It is just a tool you use to
manage your dependencies and install your project. And all of it comes as a
single phar.

    
    
      $ wget http://getcomposer.org/composer.phar
      $ php composer.phar install
    

Done.

~~~
apinstein
It matters because if you're still on a 5.2 platform you cannot run composer
without having php 5.2 and 5.3 installed side-by-side, which is a pain.

------
TamDenholm
Pretty nice idea, be good to see if it gets some traction and becomes popular.
I suppose the next step is populating it with the most popular packages and
trying to get active adoption with developers.

~~~
Seldaek
It is in the process of being integrated in the Symfony2 framework, which is
one of the largest PHP communities. That should dramatically help adoption.

We have some other plans that will help, but nothing sure. Just talking to
various people.

Ultimately though, package management is solving a big pain point. If the user
experience is good, and it is easy enough for everyone to use, I would dare
say that it can not fail. And don't get me wrong, things are not perfect yet
on that front, but we are trying hard, and we welcome any feedback we can get.

~~~
benatkin
Why are you using JSON, exactly? What's the harm in allowing comments in the
package description file?

YAML is much better suited IMO, and it has traction.

~~~
dools
I actually like having config files as PHP - that way you can not only include
comments but hack in logic if you ever have to.

~~~
bergie
We used to do that with Midgard. Just like embedding in logic into your
templates, it gives you a lot of flexibility but ultimately ends up with you
or your users shooting yourself into the foot.

For reference, here is one of the old, PHP-based config files we have:
[http://trac.midgard-
project.org/browser/branches/ragnaroek/m...](http://trac.midgard-
project.org/browser/branches/ragnaroek/midcom/org.routamc.photostream/config/schemadb_config.inc)

~~~
gambler
Using homogeneous architecture has _tremendous_ advantages over using a
patchwork of different formats and languages.

Quick example. If you're using native PHP templates and configs, installing
APC gives you instant template and config caching with zero effort. To get the
same functionality for other formats you would need to roll our your own
caching, introducing bugs and complexity along the way, but, most importantly,
reinventing the wheel.

That's just one out of myriad examples.

Also, if you have more than two nested levels of arrays (regardless of the
language used) in a giant uber-config file, you are the one who is shooting
your users into their feet.

Don't code XML in PHP. Refactor. Use includes (which JSON doesn't have, BTW).
Use autoconfig pattern and align your configuration file with classes that use
them. Use sensible conventions over configuration. Start the file with return
statement instead of magic name:

    
    
      <?php
       return array(
         'var' => "val",
       );
    

Nothing will _ever_ scale if you don't even try to design it in a sensible
way.

~~~
grncdr
I didn't know that you could return a value from an include like that, that's
incredibly handy (and makes me wonder why almost _nobody_ does it that way).

~~~
dools
I love this strategy, it's great for config. For example in the RocketSled
microframework I mentioned earlier[1] you have a config file to instruct the
system which class to execute by default in which you just put:

<?php return 'Hello World';

Being able to include a file like that in your project which returns a value
has the advantage (in my opinion anyway) of not cluttering up the namespace
with lots of defines(), of not requiring any magic naming convention, and of
not having to call out to any external functions or edit config files that are
part of the core system's version control.

[1]<https://github.com/iaindooley/RocketSled>

------
dools
This looks really cool. I've recently been similarly inspired by watching
Node.js guys (Substack in particular) and the penchant for very targeted re-
usable components.

The strength of PHP is that there's so much code already written that
monolithic frameworks are a step backwards, but a good package distribution
system is required for this to work.

I recently released a little front controller style microframework that has a
default autoloader with a simple way to register your own:

<https://github.com/iaindooley/RocketSled>

and an associated package manager that basically just has a list of github
repos and a config file which specifies dependencies:

<https://github.com/iaindooley/RocketPack>

Since I don't want to constrain myself to using only namespaced code or one
particular autoload implementation I won't be using Composer just yet (indeed
I'm an advocate of a "lazy" namespacing policy) but I look forward to
following the project's progress via github.

My goal is to use tools that don't "have an opinion" - that allow me to use
whatever is going to get the job done most quickly. Things like coding
standards, policies and aesthetics are moot when it comes to delivering code
on the day, especially if your code is highly modular and compartmentalised.

~~~
bergie
Regarding Substack code, I've made a PHP implementation of the DNode protocol:
<https://github.com/bergie/dnode-php>

With this you could actually call Node.js code from your PHP apps.

And yeah, php-dnode is available on Composer :-)
<http://packagist.org/packages/dnode/dnode>

~~~
dools
Oh cool! I was interested in dnode-php, you've already done all the work :)

/me follows

------
IsaacSchlueter
This is neat :)

I spent a lot of years in php, and the lack of a serious code-sharing story
was certainly a pain point.

Using JSON (and being strict about it) is a good idea. If people really want
to use Yaml, then they can write a composer.yaml, and have a build step that
dumps it into composer.json. Courier does this for node projects that want to
write their package metadata in coffeescript.

~~~
catch23
I wish the same were available for python. I know there's pip/virtualenv, but
they just don't come close to node's npm or ruby's bundler.

------
philfreo
git submodules can handle the basics of this decently well.

You can include any git-hosted project pretty easily with `git submodule add`

You can easily switch which commit/branch/version of the project you want to
have included. So if you want to be using the latest version of Project X +
one special bugfix that you made, just fork the project on GitHub and switch
your submodule to point at your latest commit.

`git submodule update --init --recursive` to update all the package/submodules
in your project at once.

------
jdkoeck
Interesting, how does it compare to PEAR?

