Composer and Packagist

I've now got Luminous set up to be a Composer package, and it's available through Packagist (a PHP package repository).

I am a bit baffled by Composer in general. I understand the idea of having a package manager for a programming language/environment, and PHP is sorely missing any other kind of okay-quality repository (PHP classes, ha!). Node's npm is some form of black magic and I love it. Ruby's gem is nice for installing executables (I don't write Ruby, I tried once...). Python's easy_install seems to work. Composer, by contrast, is kind of baffling.

It's a command line program, but it's not a case of composer install package, instead you need a JSON file which defines your dependencies, then you just run composer on it. Which seems odd. Easier to move between machines, maybe, but not very convenient to just drop something into your project.

My second criticism is more frustrating to me as an author. I haven't used any of the other package managers as an author/publisher, so maybe the comparison is unfair, but here goes:

Composer integrates with Git, which is nice. When you pull luminous, it looks in my public Git repo at the tags and branches and tries to match that to the version you specified. That's nice. But it rather ignores the fact that a version control system isn't a software distribution method. It can be used as one, but many projects require additional steps to transform a revision into a distributable build.

In the case of Luminous, a revision contains several megabytes of testing code and some resource intensive testing scripts (fuzz tests). These are fine on a dev box, but you really really really shouldn't even have them on a production server; it's a trivial DoS vector, and it has other implications if your server is happy to execute those sample source code files. What really mystifies me is that although Composer allows you to specify post-install scripts/commands, *these don't execute for dependencies*, only for the root project. "Great", you think, "Luminous is the root project". Well, actually, it's not: the root project is whatever installed Luminous.

This means that when someone else installs Luminous, I cannot set up their copy.
This means that when I install someone else's library, I can set it up.

As a package provider, there is no situation that I could ever write a useful post install script, and as a package consumer, it shouldn't be my responsibility to set up other people's packages. Basically, I should be recommending that everyone writes in their composer.json:

{ 
  "scripts": {
     "post-install-cmd" : "rm -rf vendor/luminous/luminous/tests"
  }
}

But I can't even do that, because there's no space for comments in the package!

Or to put it another way git clone !== install .

I've locked down the testing directory as much as I can, but even so...

You could argue that I shouldn't be allowed to run arbitrary code on other people's computers, but then I would question why you want to install my libraries.