On Fri, Sep 9, 2016 at 10:39 AM, Lester Caine <les...@lsces.co.uk> wrote:
> Having slept on the discussion about people today expecting users each > to have their own environment, I came to the something of an impasse. > How many Linux installations run a package manager that allows > individual users to install their own versions of > Apache/PHP/Database/Git/Hg and so on. usually it isn't the distributions jobs to do that thanks to the spread of virtualization and containerization but even distros moved to a direction where you can install multiple versions in parallel or run multiple instances of a service with different config. some distros like gentoo supported this since forever, others only changed recently (for example Ubuntu changed their package naming scheme with the latest lts which is a big step to the parallel versions), and there were other projects which was created for the specific purpose of installing and running multiple versions in parallel (https://github.com/cweiske/phpfarm and https://github.com/phpenv/phpenv for example) and if we move away from php, and check out other similar languages like python or ruby, they also moved to the direction of allowing the application to specify it's own environment: with ruby they have https://github.com/rbenv/rbenv https://github.com/rvm/rvm to let apps specify their ruby environment, and there is also https://github.com/chef/omnibus for creating a self contained application which brings it's own embeddid environment so it has zero external dependency. with python you https://github.com/pypa/virtualenv and have https://github.com/yyuu/pyenv and there is a tool ( https://github.com/pantsbuild/pex) which can be used to create a single executable file which contains and executes your python application together which it's dependencies. > The whole point being that the > machine has a consistent framework that everybody knows. Even adding > extensions to PHP they will be added to the single version, which is why > I expect extensions like 'composer' to be installed centrally so when I > run it I know it's the same version that every other tech is using. > this is the old school way of doing this, and was mostly superseded because each application has it's own set of requirement (for dependencies and for configuration options) and when you want to manage multiple applications in a single environment it will be either hard or impossible. of course the system wide installation philosophy is still fine as long as you only manage a single application in that system. > > Now I have no problem with each user pulling their own clone of the code > via Git or Hg and creating their own 'play area' to check out bugs and > there is nothing to stop them running multiple copies of the PHP code > against the central web services. They are testing in parallel with the > live code in an identical environment. But obviously it would be safer > to have a second mirror machine installed with the same version of > distribution on which to test, and in an ideal world one would update > the development machine, run all the test and ensure there are no > problems before allowing the production machine to roll over. I did say > ideal ;) indeed, and you want to have a reproducible environment for other reasons too. > Most sites will skip whole major versions of updates simply > becuase their production system IS working ... > usually it is easier to migrate in multiple smaller steps, but of course there are people who will do the one big upgrade. > > Back to PEAR ... what happens if I simply install a copy of composer > centrally and rename it 'PEAR'. composer.phar simply gets installed > centrally and any new tech has access without having to install their > own copy. as I and others mentioned before composer does user/system wide installations: https://getcomposer.org/doc/03-cli.md#global but not sure what do you mean renaming it to PEAR, they have different command line format, etc. you can't just rename it and expect it to work. > As with Git/Hg users can have their own play areas USING > composer, but to be honest from a safety point of view one knows that > the version of composer being run has not been infected with some > injection mechanism. We keep going on about validating the PHP code > against malicious attack, but the whole framework is open to that? > not sure I follow what are you trying to say here, so from the past your devs were not allowed to add new PEAR dependencies, but someone else did that for them? and now you are afraid that if you introduce composer they will install random packages they will introduce something malicious? First, if adding PEAR packages was a burden in the past, I'm fairly sure that you have a couple of PEAR packages just manually committed to you repository as part of your project. with composer you don't push your dependencies to your repository, but with the composer.lock you can guarantee that installing the dependencies will be reproducible and you can scan/review your dependencies either periodically or on-demand when your composer.lock has been changed. also, if you want, you can opt-out from using https://packagist.org/ and either explicitly use git trusted git repositories as package source, or even use your own trusted mirrors. but this isn't a topic for internals@, but more suited for https://groups.google.com/forum/#!forum/composer-users -- Ferenc Kovács @Tyr43l - http://tyrael.hu
