On Fri, Sep 9, 2016 at 10:39 AM, Lester Caine <lester@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
