Hacker News Reader

Comment by svnpenn | Hacker News Reader

I stopped using PHP. The language itself is fine, but PHP doesn't include a package manager. People will shout "but composer!", That is not PHP. That is a third party tool. What Rust understands, what Go understands, what Ruby understands, is how important the package manager is to the language.

No one is an island, and "batteries included" only gets you so far. In my mind, PHP is in line with C, with the mindset of "figure it out yourself" in regards to packaging. That's not acceptable.

View on HN

Everyone has standardized on Composer. It's a better package manager than NPM, doesn't have many of the security problems that plague NPM.

The PHP internals maintainers don't have the time to maintain a tool like Composer alongside the rest of the language. And if it was bundled with PHP, it would be stuck in lock-step with PHP version releases, which means improvement can only be made once a year, basically. That's not acceptable. Composer wouldn't be what it is if it had to release so slowly.

I dont care. Plenty of other languages manage it, so for those who dont, its just excuses.

It seems like you have an unexamined presumption that bundling a package manager with a language is a superior practice, and you "don't care" about any argument that might challenge that.

The PHP community gets on fine with Composer, no need to bundle it in the language IMO

> And if it was bundled with PHP, it would be stuck in lock-step with PHP version releases, which means improvement can only be made once a year, basically. That's not acceptable. Composer wouldn't be what it is if it had to release so slowly.

CPAN is bundled with Perl, but CPAN can update itself to a newer version (try `cpan CPAN`). Similarly, NPM is bundled with node.js, but NPM can upgrade itself to a newer version (on Linux/Unix/macOS by running `npm install -g npm@latest`; unfortunately doesn't work on Windows for whatever reason.) Why couldn't Composer use the same model? Composer supports updating itself (when installed as a PHAR) via "composer self-update". So bundle the PHAR with PHP, and then when you run it, can check for a newer version and print a warning if there is a newer version available, and in response to that warning you can run "composer self-update".

> doesn't have many of the security problems that plague NPM

Is that true? How so?

I'm a long-time PHP dev, but of the issues I can recall regarding NPM, including the recent controversy related to the invasion of Ukraine, I don't see how that sort of thing couldn't happen with Composer some day, and it might just be a matter of time; that it hasn't yet has more to do with the relative ecosystems of the two languages and the developers they attract than anything technical, in my opinion. But I'd love to be proven wrong.

With NPM, what's actually published is not what's in the git repo, so it's harder to inspect/review vulnerabilities or hijacking. With composer, what's in git _is_ what composer pulls (with the exception of rules in .gitattributes to exclude files etc), making it much easier to trace. One such example: https://github.com/faisalman/ua-parser-js/issues/536

Composer packages are vendor namespaced, so hijacking an abandoned package is not possible (and it is with NPM), some examples like https://www.theregister.com/2021/08/10/github_npm_package/

Composer packages also don't tend to have the "culture" of having a million tiny packages for small functions like left-pad, so that helps a ton too. Mostly because PHP's stdlib is pretty great by default, so lots of things like this don't require 3rd-party libs.

Obviously Composer isn't bullet-proof, someone controlling a dependency of an important project can still cause harm by making a minor version release with malicious code, but it's easier to vet a smaller list of packages in the tree, especially if all you need to do is scan through their code on github.

Thanks for the response. I didn't know that NPM packages aren't just Git pulls as they are in Composer. That's surprising. I wonder why they decided against implementing it that way - it seems like just using Git or other package managers would save from having to deal with hosting, versioning, and so many other things inside the manager system itself.

Generally, NPM packages are transpiled/minified with webpack (or w/e newer tool) and published as minified bundles. That's why it's done that way. It avoids committing the webpack compiled dist to the repo.

With PHP, since there's no compile/minify step, there's no need for "build artifacts", so you can grab the code directly and run it as-is.

But obviously this has big supply-chain security downsides.

Is Ruby Gems a first party thing now? I remember, back in the day, being tangentially involved with creating a Ruby package manager before Gems had become the de facto standard.

I think Pear was the equivalent of Python's pip way back. Haven't really looked back since composer dropped.

what a strange hill to choose to die on. what would be different if composer came bundled with the PHP runtime?

I wouldn't have to install it...

This sounds like an objection based on a personal principle.

I think if you tried explaining your design choices like that in a technical interview, or to a teammate, they may not be persuaded.

If thats your only argument, FWIW Pear and Pecl typically were both bundled with PHP.

Nitpick, but Go the language doesn't have package management. The 'go' tool -- an implementation detail of the most popular implementation -- has features for fetching packages, etc., but the language spec does not require these features or constrain how they work.

What a small reason to decide on what language to use. There are far bigger reasons to choose a language but it's your choice.

How is it any different than Python (pip) and Java (maven, gradle)?

> Java (maven, gradle)?

Its not, I dont use Java either, same reason.

> Python (pip)

Python comes with Pip, at least the one I use anyway:

https://nuget.org/packages/python

You are logically inconsistent then with regards to Python. Your distro might bundle it out of convenience but its not a first party component.

OK, does PHP do that?

Does PHP control nuget packages? No. No they do not. Neither does Python (the python package you linked to is managed by a Microsoft employee).

Seems petty to me. Who cares if it's not first party? It's widely used and is the defacto standard package manager. Is that not enough?

Reply on news.ycombinator.com