Hello, For myself I have adopted the "vagrant vm per project" workflow. I never mix projects, because while some are "primitive" and do not require anything beyond a standard install, others have a custom provisioning and setup stuff. And specific options on the software that can interfere with other projects. Not to mention that I do really juggle between 5.5, 5.6 and 7.0 versions right now (and moving things to 7.0 as I'm able to). Even for Laravel I do a per project install of homestead. And I also work under Windows, many of my colleagues do Linux or Mac OS. Having a fully self-contained projects helps to avoid issues between our systems.
I also do cleanup wm's that I do not need for some time, that clears out the space on the disks, especially when databases are several GB big. On Fri, 9 Sep 2016, 15:33 Ferenc Kovacs, <tyr...@gmail.com> wrote: > On Fri, Sep 9, 2016 at 1:45 PM, Lester Caine <les...@lsces.co.uk> wrote: > > > On 09/09/16 12:35, Ferenc Kovacs wrote: > > > but please, this is really offtopic on this list. > > > > See my other reply ... > > and composer global mode as provided out of the box is NOT an > > alternative to installing the sort of production and development - > > command line - tools that PEAR currently manages happily. I AM trying to > > learn composer, and I can see now how it can be used, but simply passing > > the buck to getcomposer is not the way to use it for a default PHP > > installation. > > > composer is proven to be capable managing those use-cases but it isn't our > duty to write out the detailed migration guides for every usecase between > PEAR and composer. > our duty as the php-src group is that we provide a way which allows the > management of the pecl extensions (pickle install and maybe providing an > alternative for pecl package) and tell people how can they install PEAR if > they still need it (https://pear.php.net/manual/en/installation.php) > for the record most distributors already decouple PEAR from the base php > install (php-pear is a separate optional package on debian/ubuntu, the > windows binaries doesn't have PEAR at all, you have to manually install it > there, etc.) and from the php-src point of view we only use it to provide a > way of installing pecl extensions, which will be solved with pickle so > while educating people to migrate their workflows from PEAR to composer is > a noble goal, but it isn't our responsibilities and we don't have to solve > that to be able to replace our php c extension management tool shipped with > the core. > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu >
