Comment by mschuster91 | Hacker News Reader

Comment by mschuster91 | Hacker News Reader

Parent Full thread

Well, composer needs to be installed and present on the system. As the author states, minimal dependencies.

Hell why doesn't everyone follow this? Instead I see projects with five or more build tools needed to deploy a website.

A single small website depending on... PHP/MySQL (obviously), Symfony, composer, npm, grunt, bower, ant, vagrant, docker. And well, language dependencies not needed by the website itself, just for the buildtools: python, nodejs, ruby, java plus virtualbox for vagrant!

All of this for a setup that can be (with proper documentation) replicated by hand and from scratch in <10 minutes (Debian, not RPM-based crap). The fuck are you smoking, people? Took me even WITH documentation about all those build tools 30min to get running where a simple git clone should be all that's needed. Bonus side effect: if you need to hack stuff in your deps, it's easier to ship them in your repo than if you use composer and friends.

I'd coin a new term for this: tool-sturbation.

I agree with you that modern web projects tend to suffer from build dependency creep - but I don't think Composer alone really counts as being heavyweight or unnecessarily complex, even for a small project. It's just a phar archive and a json file. That's not really the same class of insanity as, say, requiring the Node.js runtime and npm to import a build system to compile the CSS assets for a PHP project.

Even if structuring a project around the PSR autoloader adds a bit more complexity (probably little more than adding a namespace and moving everything into a folder) that's still preferable to the dark days when everyone just rolled their own autoloaders (if you were lucky) or you were expected to do it yourself (and then maybe everything gets wrecked because of a relative path somewhere in the mass of includes of includes.)

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.

> 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.

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.

> 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?

>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.

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).

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

> 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.

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.

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)

"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.

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.

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.)

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.

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.

> 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.

Reply on news.ycombinator.com