[debaserab2]

Who says you need those build tools? That has nothing to do with sane package management, which is what composer provides. Composer doesn't require you to have any dependencies and you can use a library that supports composer in the exact way you described. It's just a JSON config file, there is absolutely no reason to not set it up - not having "dependencies" is not a valid reason.

[mschuster91]

> Composer doesn't require you to have any dependencies

Oh yes, it does - SSH or other shell access, as well as the hoster allowing the server to connect to the outside Internet!

Both are not common, in fact many hosters firewall their hosts for outgoing connections to prevent spam, botnets etc.

[bluehazed]

I'm really not sure if this is sarcasm/trolling or not, but just in case it's not, composer is mainly used on the development side to maintain dependencies. It really shouldn't be a problem to have ssh/a working internet connection on your development box. Not saying you have to use composer, but I think the above point stands.

[mschuster91]

> composer is mainly used on the development side to maintain dependencies.

Well you will also need composer for actual deployment.

> . It really shouldn't be a problem to have ssh/a working internet connection on your development box.

Ever worked at a BigCo where everything is firewalled and needs a proxy? Or no internet at all and you gonna transfer stuff via USB sticks?

[krapp]

>Well you will also need composer for actual deployment.

No you don't, it's PHP, there is no "actual deployment" beyond putting the files on a server.

Worst case scenario (because I've had to do this) is you have to change the paths in the file generated by the autoloader, if your development environment is different than production. But that's no more work than adding paths to include statements. You can even just do that locally first and move everything with FTP.

[debaserab2]

No, you don't need it for deployment at all - a very common and sane deployment strategy is to have one developer / staging environment that does composer install/updating, and then the result of that build is rsync'd (or it could be FTP'd over in a shared hosting environment) to the production host(s).

[teh_klev]

> many hosters firewall their hosts for outgoing connections to prevent spam, botnets etc.

That's not really true. Even on our shared hosting platform (non-shell) we permit http/https/ftp outbound connections, and we're pretty conservative.

We also expect our customers to build and test their stuff locally then push up a working and hopefully error free site to our servers. We consider our servers production-only environments and will actually take you down if you're generating more than a few errors an hour, because errors and exceptions are expensive.

That said I do kind of agree with your sentiment about some "simple" projects that use everything under the sun just to get a todo list app built, even on my local dev env.

[jasonlotito]

Adding composer support doesn't make the package incapable of being used exactly as it's being used now. It merely adds support. You can theoretically install any composer package without using composer. Though, those with complicated dependency trees would be more difficult. That, though, is not an issue here.

[cfv]

You can always do a local deployment, zip the thing, and rsync it anywhere. It's not at all a necessity, it's just that most PHP devs have embraced Composer.

In fact we used to do something rather similar at my job, until we just switched to replicating containers over all our servers