I know we don't want to use Composer because some people won't have it installed and that's another thing we'd need to support. Instead of having the users run Composer commands, can we, as developers, use Composer to install third-party stuff and then distribute it?
What is Composer ?
It's the first item in a Google search for "composer".
LOL Joshua ;D
This ?
https://getcomposer.org/
Actually that's not entirely true, at least for me (and if I said that I was probably drunk).
I'm fine with Composer, I used it in OpenImporter. What I think we should pay attention is the way we release: at the moment is not uncommon people pick the whole repo and just overwrite the existing files. Using Composer this could be a bit more tricky, so I'd like to have a more frequent release cycle before switching to Composer (let's say once a month), or at least have a "buildbot" releasing nightly builds, so that anyone wanting to test the code could just download and play with it.
At the moment I have a spare-to-be-dismissed VPS that I can redirect to be a buildbot, there is "just" to write the backend. O:-)
FYI, if it helps, another project I follow use Composer for its development environment but builds a snapshot of the libraries into the release version for use on Shared Hosting. That could be a way to go, then, and you'd also encourage more people to use release versions (aka stable) on shared hosting which is what most people will have, rather than trying to use development nightlies.
Why can't shared hosts use Composer? It uses a Phar which is just PHP. The only reason they wouldn't is because they are using an old version of PHP (< 5.3) and I thought the next version will require >= 5.3.
It's pretty hard to install Composer on a shared host if it's not already there. And most of the big hosts don't care enough to cater to people who want special features.
You don't need to install Composer. It's a Phar. You can just drop it in and run it.
The only issue would be if you don't have shell access. There is a solution - http://stackoverflow.com/a/26277355 but I suspect that many hosts would still not allow the requisite commands.
For that, we could just use Composer's API. Looking for some tutorials on how to do that now.
Non-jailed shell access is the biggest problem, yep.
Yep, that was my idea when I wrote the post above: have a cron that builds snapshots on a... daily basis for example. And when a release is ready, prepare the package including all the dependencies (i.e. add a step to the packaging procedure to run composer).
I am trying to install Pimple via Composer in a branch. I want to commit Pimple but it seems that vendor files are ignored. Should I just unignore it, commit, then ignore changes again or is there another strategy that people are using to add to vendor? Is vendor not supposed to be used like that?
Why not just the composer.json? Apart from what I wrote above. :P
I added it to composer.json and it doesn't get committed because /vendor/* is in .gitignore.
I mean: if it is in composer.json, anyone can just run composer install and get whatever is needed (in a development environment, the "user-environment" is another thing, I'm specifying this before people get scared by having to run commands, don't worry, in case we ever end up using composer it will be just for development, not for the normal usage), that's probably why I added the vendor directory to the gitignore, because I have some stuff there and didn't want it to end up in the repo (what's the meaning of have pimple in the repo when we can get the most up to date whenever we want? O:-)
Well, you don't always want the most up-to-date package. It might be outside of your minimum versions and won't be tested. So, you use Composer for development but we should ship two packages - with the downloaded packages and without.
If I didn't include it in the repo, when you built the package it wouldn't be in there.
I thought I added Composer and its lock file for the phpunit tests with Travis. Then again that's probably just my CRS syndrome kicking in. Never mind me, I'm just off in the weeds anyway :P
It's there. It works. There is nothing wrong with Composer. It's that when I use it and try to commit Pimple, it doesn't commit because the vendors directory is ignored.
Ok, I'm likely missing something. O:-)
composer.json has inside a command along the lines: "install this version of Pimple".
And when you run composer install it grabs that version of Pimple.
Right?
Now, my doubt is: why should we have the whole Pimple at a certain version in the source tree?
Isn't it enough a string in composer.json like I did for OpenImporter?
https://github.com/OpenImporter/openimporter/blob/development/importer/composer.json
but there is no "vendor" directory:
https://github.com/OpenImporter/openimporter/tree/development/importer
when there is to package I run composer install, the vendor is generated and I zip everything together (actually I could even remove composer.json and composer.lock).
Why should I put Symfony/Yaml, Doctrine/DBAL and Symfony/Class-Loader under version controls? O_o