[blueflow]

I'm working with a customer right know that doesn't even have shell access on their hosted environment. composer and git are barely usable under those circumstances.

I don't have reliable information about the market situation, but i assume that this is pretty much standard with shared hosting.

[mschuster91]

I am working with hosters still running PHP5.2 in production... FTP only.

[ceejayoz]

Someone on ServerFault was posting about their PHP CLI on their shared host being PHP 4.x this week. Yowch.

[mschuster91]

Hoooooly shit, I'd change the hoster for fear of being hacked lol

[debaserab2]

No reason why composer would be unusable - just composer install locally and upload the results to your host. This isn't an uncommon deploy practice even if you have shell access.

[mschuster91]

It's a PITA if you're developing on Windows. The less you have to do other than FTP upload, the better because SOME incompatibility WILL fuck you up. Wrong CRT version, weird path issues, package installers assuming Unix... dependencies on stuff that doesn't work on Winblows, requires PECL extensions (which are regularly unmaintained on win32),...

[krapp]

Not in my experience - I develop PHP on Windows and have never had an issue using Composer. I can't imagine what sort of PHP dependencies "don't work on Winblows (cute)" or which even care about your CRT, or how that would even be a Composer issue as opposed to an issue with the libraries themselves or your PHP install. It's just PHP scripts running from an archive - if PHP works, and isn't too out of date, Composer works.

[debaserab2]

Developing on a VM solves all of these problems. Your dev environment should match your prod environment as much as possible, anyways.

If your target host is *nix, develop on something unix-like.

[aioprisan]

What I meant was develop locally, use composer locally, then deploy the end product over, which sounds like all environments would allow you to do.