On Thu, Sep 8, 2016 at 3:18 PM, Lester Caine <les...@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, and > > 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 — 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
