Hacker News new | ask | show | jobs
by jnardiello 3846 days ago
You just don't get it :)

Whoever wish to include manually this package and use it like if it was 1993 will still be able to do by cloning this repo and including the file by hand. On the other side, 99% of the sane PHP that has been written in the last few years including fairly large projects, WILL use composer to manage external dependencies as it's probably the single project who made PHP a modern language.

So, what are the cons of releasing this as a package?

I'm not even starting the conversation where I'm trying to convince you that using a dependencies manager is always a good thing to keep the codebase sane and clean - even for small scripts. That "<10 mins thing" is an empty claim as you have to do a boilerplate once and can use it all the time (unless you are the kind of programmer who is not 'good-lazy' but rather 'bad-lazy' and love to re-do its job by hand over and over)

2 comments

"99% of sane PHP" is not the audience here. There are millions and millions of shared hosting accounts running basic cPanel + PHP + some minimal form of SSH access - those are the people that won't have a way to install LetsEncrypt otherwise, except for the ability to execute some random PHP file in their SSH home directory. Step out of your walled garden and buy yourself a crappy $5/mo hosting account, and you will see why the author's choices are a blessing in disguise.
A pity you're being downvoted. People forget not everyone has the bucks to shell out for even a webhost with SSH enabled.
$5/mo shared hosting plan where you're walled and can't do anything you want, or $5/mo VPS at Digital Ocean where you have SSH enabled by default and can install anything you want.

of course, people don't have the bucks to shell out for that. I get it.

> of course, people don't have the bucks to shell out for that. I get it.

they don't know better. Don't forget what the base of most Wordpress and Drupal setups is - people with barely enough skill to do a FTP push, download and install a theme from Themeforest and done.

or they can't pay because nearly every US startup/service accepts credit cards only (which is not widespread in Europe) and no one really trusts Paypal.

> they don't know better. Don't forget what the base of most Wordpress and Drupal setups is

Considering the audience of HN, I am astounded by the amount of people who complain about a PHP package being on Composer, yet they all use NodeJS, Go, and other things that require more than modern PHP and Composer does.

Most people are not likely to know how to manage a VPS. There is a fundamental difference.

A managed hosting company does something important for you. They manage!

For the average user, this is something they need if they want to start a small business or a website for a project and want to have SSL while doing so. Integrating this with some form of tutorial for the average user makes this tool amazing.

You can still use a Composer based project without using Composer, though. You can still just FTP the thing up to your server and include it manually, as long as it doesn't include its own dependencies (and if it does, you would have to manage those manually anyway.)
Adding composer support would not impact people's ability to use this the way they would now. Composer support doesn't stop manually installation. It's akin to supporting npm. I can use npm to install packages, or I can manually add them if I wanted.
You can always distribute a "full" package like many popular products do, with all the dependencies lodged in place. It's a damn convenient thing to have at dev time, but there's 0 need to enforce build processes in PHP at least.
Sorry, but most hosts have composer installed, it's the preferred way to install PHP packages.
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.

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

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.
> unless you are the kind of programmer who is not 'good-lazy' but rather 'bad-lazy' and love to re-do its job by hand over and over

Well. If you do it by hand you know WHERE and WHY it didn't work in case problems arise. Granted, it takes experience in server management, but imho a good developer MUST know about the platform his software is to run.

The more tools you add to the process, the more complex debugging gets when even the tiniest dependency chanes.