5 ms·

Sorry, but most hosts have composer installed, it's the preferred way to install PHP packages.

blueflow 11y ago
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 11y ago
  I am working with hosters still running PHP5.2 in production... FTP only.
  - ceejayoz 11y ago
    Someone on ServerFault was posting about their PHP CLI on their shared host being PHP 4.x this week. Yowch.
    - mschuster91 11y ago
      Hoooooly shit, I'd change the hoster for fear of being hacked lol
- debaserab2 11y ago
  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 11y ago
    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 11y ago
      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 11y ago
      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 11y ago
  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.

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 11y ago
I am working with hosters still running PHP5.2 in production... FTP only.
- ceejayoz 11y ago
  Someone on ServerFault was posting about their PHP CLI on their shared host being PHP 4.x this week. Yowch.
  - mschuster91 11y ago
    Hoooooly shit, I'd change the hoster for fear of being hacked lol
debaserab2 11y ago
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 11y ago
  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 11y ago
    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 11y ago
    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 11y ago
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.