Q: Which has better packages, Python or PHP?
It depends on the target utility. In the Python world, the most common package installer is pip
; the PHP world didn’t settle on a dominant format/installation for packages until composer, and that was relatively recently (last 4 years).
…
The reason for this is because PHP is a language almost exclusively designed for websites, and the economy of the open-source world has found that a dedicated application, instead of a framework or library could serve the bulk of most commercial needs. For instance, a single application, WordPress, four years ago (2014) accounted for nearly 20% of all websites and 50% of all blogs. There is little need package management when a single download and install (or a single click during ISP/hosting account creation or visit to site like Bitnami) can set up everything a typical website might need, fully under your control, with its own package infrastructure (plugin and theme ecosystem) where the underlying language (PHP) is pretty much irrelevant to the user.
Other languages like Ruby (with gems) or Go (import
) or Javascript (with npm
) which matured later and are more general purpose had a more robust package management and installation system. PHP Composer, in fact, is most modeled on npm.
Python, like Perl, predates these languages, but its general purpose demanded package management early in its development. However, because of this, pip takes less advantage of web conventions that npm does. Python has the added headache of version compatibility with its core runtime. Still pip is perfectly workable and relatively seamless and easy to use.
…
So which has better packages? The answer is it depends on the domain. In nearly any language you can find an adequate package for any of your needs, but overall you will find the packages are higher quality, more up-to-date, and sometimes just better overall in the domain the language seems to target well.
In my opinion, packages for data science/AI/ML applications, Python packages are second to none. As a PHP expert, I wouldn’t even bother looking in Composer for them and would instead find a PHP extension that binded to a dedicated engine optimized for the problem area or write a dedicated solution/web service in Python/flask and call it from PHP. If, for some crazy reason, I needed to do this entirely within PHP, I would search for the best solution in Python and see if someone has a port for that in PHP.
I would expect the same in DevOps for Python, but right now that space, like blogging (WordPress), seems to have dedicated solutions where a domain-specific language has abstracted one from the language-specific package management solution. For instance, in the configuration management space the top four applications are: Puppet, Chef, Ansible, and SaltStack. Of those four, I believe only one (Chef) exposes the underlying language (Ruby), and it does this to the DevOps engineer no more than WordPress exposes PHP to a blogger.
For server-side web-based packages, I feel PHP and Composer are going to have a solution for any problem PHP itself is capable of solving. That is a restricted set, however, as more and more work for web applications is being done on the client-side in Javascript and there is already an adequate toolchain for that (as well as a package management system in npm). Other web-based languages will probably have adequate solutions in this space with decreasing order/quality: Ruby (on Rails), Javascript (NodeJS), Python, Go, Perl, Java… The web problem is now pretty discovered at this point so there is less a need to adopt the bleeding edge in the web problem.