5 ms·

I am one of the guys behind http://pearfarm.org http://pearfarm.org. I mention it just to show I've thought a lot about this problem. What's interesting is tha

I am one of the guys behind http://pearfarm.org 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 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.

bergie 15y ago
See the easy for developers part on why I think this has better chances than PEAR did.
- apinstein 15y ago
  PEARFarm, pearhub, and phark all made it easy to create packages, so I don't think this is going to be the silver bullet to broad adoption.
Seldaek 15y ago
1) It does support PEAR, it's listed on http://packagist.org/about-composer 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 https://github.com/composer/composer/issues/57 - but this depends on other features that we need to finish first.
- apinstein 15y ago
  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 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.

bergie 15y ago

See the easy for developers part on why I think this has better chances than PEAR did.

apinstein 15y ago
PEARFarm, pearhub, and phark all made it easy to create packages, so I don't think this is going to be the silver bullet to broad adoption.

Seldaek 15y ago

1) It does support PEAR, it's listed on http://packagist.org/about-composer 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 https://github.com/composer/composer/issues/57 - but this depends on other features that we need to finish first.

apinstein 15y ago
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 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.