Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95817
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain daveyshafik.com from 209.85.220.177 cause and error)
MIME-Version: 1.0
Sender: me@daveyshafik.com
In-Reply-To: <9bc67943-4b45-ba8c-6edd-f6560fd233d5@lsces.co.uk>
References: <CANaX5nf5S6aS-ZaB=51qvXv+wbReGb2petPBDogTA+MNMHyysQ@mail.gmail.com>
 <04998da0-6344-0b8b-c69a-411400e340ba@lsces.co.uk> <1473323097.1378681.719308017.2139F909@webmail.messagingengine.com>
 <8493a9dd-1f0e-f15f-3651-0278cf25234b@lsces.co.uk> <ec690b39-00d3-b2f7-60e7-5dd5b30cd7b3@gmx.de>
 <e8584697-8efe-e933-ca74-a404c92c30ec@lsces.co.uk> <CANUQDCgfcFtTOmKYj0osvsOwVOi2Y3SkAXGFyVdsFh0-UR04aA@mail.gmail.com>
 <bac1fc14-99bf-fc2e-39ce-a1662092785d@lsces.co.uk> <CADMz3weWurQpusUSkCx=25c6fxuWArSzQaedr4HnGVrLc11PzQ@mail.gmail.com>
 <3ec68c67-a4de-1727-c3c8-e8fcacd95f0c@lsces.co.uk> <b9ea0155-2f4b-bbfe-2ecd-6e7700147ad4@garfieldtech.com>
 <9bc67943-4b45-ba8c-6edd-f6560fd233d5@lsces.co.uk>
Date: Thu, 8 Sep 2016 16:19:44 -0700
Message-ID: <CANaX5nffwcwrN5mH3Ch9+_DX2b-uKF2f9yHBWO9-zfufyFQ0oA@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1149b404e0ff86053c074319
Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace withcomposer/pickle
From: davey@php.net (Davey Shafik)

--001a1149b404e0ff86053c074319
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 8, 2016 at 3:18 PM, Lester Caine <lester@lsces.co.uk> wrote:

> On 08/09/16 18:40, Larry Garfield wrote:
> > Note: Whether that is a good trend or bad trend I will not claim, and
> > that is largely irrelevant.  But that is where the river is running, an=
d
> > trying to swim upstream against it is not going to be very effective.
>
> Trying to swim against the tide of M$ 'improvements' has been something
> I've been doing since 1992. Silly little things like when you remote
> access a local server which in addition to serving web pages is also
> displaying the information on monitors, and creating announcements via
> the PA system. Does the M$ remote desktop offering still switch off the
> local sound card 'to improve the remote performance'? I still use VNC
> simply to ensure the locals site is NOT brought down. And the local
> technicians  have to log in via their own accounts so unless care is
> taken, NONE of the shares or tools they need are available because of
> the move to secure activity between accounts. ALL of the work being cone
> by these machines is central, and every user needs to see the same set
> of tools, and file system. They do not need to live in their own little
> world secure from other technicians and they ALL need to see the same
> desktop.
>
> Of cause where sites are not being heavily audited for security we can
> stick up two fingers and the only active user is root - totally
> politically incorrect - but it prevents the bulk of the problems caused
> when some 'developer' screws up something global after a Linux update.


There is a fundamental difference of approach here. In the modern approach,
the ideal is easy replication of _exact_ environment somewhere else.
Whether that be your laptop and desktop machines, your machine, and your
team members, or your machine and a cloud providers ephemeral instance. Or,
in this case: between users on the _same_ machine.

The point of the composer.lock file is that a "composer install" command
will installs the _exact_ same versions everywhere. Even if it's coming
from VCS, it'll record and install the same commit everywhere. It even
records the shasum of the versioned package, so that if the server replaces
it then you'll know.

The primary issue in your case is that you're duplicating the files for
each user. There is nothing stopping you putting the code in a single place
and doing a composer install then making sure all the users can access it,
whether through symlinks, or just simple permissions (and possibly PATH
changes).

In your case, I think the reason you are centralizing is because you want
to ensure nobody touches the file =E2=80=94 this is more about security and=
 lack of
trust, than anything else. Typically, there is more security in this
approach, as nothing is owned or run as root.

Anyway, this is far off topic IMO. This RFC isn't going to kill PEAR (any
deader than it already is :P) it will simply unbundle it from core. If you
want to continue using it, then by all means do so. And ignore the
potential fact that composer/pickle may be bundled instead.

- Davey

--001a1149b404e0ff86053c074319--