Installation instructions on the Getting Started page does not mention OS packages
loop54-christoffer opened this issue · comments
The easiest way for new users to install Composer might very well be through the packages that come with their operating system (e.g. composer on Debian-like and RHEL-derivative systems). I think this option should at least be mentioned on the Getting Started page. Is there a good reason it's not?
I should add that as with #172, I can probably add a PR if there's general agreement around this being a good idea.
The easiest way for new users to install Composer might very well be through the packages that come with their operating system (e.g.
composeron Debian-like and RHEL-derivative systems). I think this option should at least be mentioned on the Getting Started page. Is there a good reason it's not?
That's not officially supported by the composer team, because these packages are shipping totally outdated versions of composer.
On Ubuntu, here are the versions available (see https://packages.ubuntu.com/search?keywords=composer&searchon=names&suite=all§ion=all):
- 16.04 LTS: Composer 1.0.0-beta2. Released in March 2016. Incompatible with packagist.org (which uses features added in composer repositories after that date as the original format was not scaling)
- 18.04 LTS: Composer 1.6.1. Released in January 2018. Not sure it is compatible with packagist.org anymore. To be tried if someone is curious.
- 20.04 LTS: Composer 1.10.1. Released in March 2020
- 20.10: Composer 1.10.10. Released in August 2020
The goal of the Composer team is to push adoption of Composer 2 as soon as possible, so that packagist.org can ultimately remove support for the v1 metadata format (which is much more costly than the v2 format). If the OS packages become the recommended installation way, this plan is dead immediately and probably for the next 5 years at least (Ubuntu 20.04 is supported until April 2025).
Ah, I was worried there would be a problem along those lines. In that case this issue can be closed!
(For the record if you're curious, I have some recent experience of Ubuntu 18.04 in production and the package manager-installed composer works with packagist.org there.)
For the record if you're curious, I have some recent experience of Ubuntu 18.04 in production and the package manager-installed composer works with packagist.org there.
If you install from lock (which I hope you do on production), you are not using packagist.org. Packagist is used to get the metadata for composer update and composer require (and some other helper command relying on available packages)
Aha! I didn't know that bypassed packagist.org, but it makes sense now that you say it. Thanks!
Well this is rediculous and a kick in your own plan.
We run plenty of servers here, all with automatic updates using apt and we're still stuck on v1.1
The reason it's stuck isn't because of the Ubuntu developers, but instead because no one has taken ownership over the PPA (likewise for other systems).
Of the options for maintaining an up-to-date version of composer on systems, you've picked the least secure option that also requires the most complicated set up. Don't try to re-invent the wheel - it'll make system managers very unhappy. If all systems went by updates like Composer has, server upgrades will become incredibly complex and the number of people running old outdated versions will increase exponentially.
Here are three other options, and both will improve the adoption rate of v2, in order of preference for maintainability of servers.
- Perform regular updates working with Ubuntu in a similar way to most standard packages
- Create your own PPA (and similar for
yum), similar to PHP7, allowing you complete autonomy in upgrading as you need - Create your own version application, like NVM
And why would we go through the hassle of maintaining a PPA & equivalent for every linux distro out there? How is this our problem or responsibility? We aren't reinventing the wheel, we are providing a simple way for people to install and keep composer up to date, which is cross-platform. If people want to install via system packages they are welcome to, but then someone is going to have to take the responsibility for the PPA.
Hardly difficult "for every linux distro out there" - basically just yum and dpkg. It takes 5 minutes, and means system administrators can maintain your app through their standard apt library. I've also detailed other ways. Five minutes of your time every two years, will have seen a much greater uptake in Composer 2.0. Five minutes of your time is the equivelant to cumulative days of system administrators messing around to get the latest composer.
You've re-invented the wheel with your "script" for installing, and introduced another place for security vulnerabilities. The point of package authorities as used by dpkg and yum is to deal with the security of installs accordingly, but I see you'd rather re-invent the wheel, and spend more time maintaining this than actually getting updated versions out to the majority of servers.
For this reason, no system administrator in their right mind will automate your script, and as such, your claim below is clearly not the case,, otherwise you'd be doing all you can to encourage system administrators to upgrade to Composer 2.
The goal of the Composer team is to push adoption of Composer 2 as soon as possible
An even better idea than my previous ones: speak to the PPA maintainer for PHP about adding composer to that.
Here's some help http://ppa.launchpad.net/ondrej
I sent a DM to Ondrej last night, but I also know he's busy enough as it is, so I don't know if he'll consider taking on more work for fun.
As for not reinventing the wheel, you may not be aware of it but there are other operating systems than those using yum/dpkg. We need to serve all our users. Anyway I'm done here.
there are other operating systems than those using yum/dpkg
Correct, but as far as servers go, the majority are maintained through yum and dpkg.
Providing the download as you do caters for those installing on Windows just fine (chocolatey is just not suitable) and for OS X users, whilst they tend to use systems similar to yum and dpkg, they are generally not used as servers in the cloud and instead as development or local servers.
Worth taking note, you have two different use-cases: servers and development machines. A manual process for updating is only suitable for one of those use-cases.