"Niklas Keller" wrote in message news:canuqdcjeh45_2aeq74cceoy4xc3xj0o_+yrq2nvy0k2vdox...@mail.gmail.com...

Tony Marston <tonymars...@hotmail.com> schrieb am So., 4. Sep. 2016, 10:38:

"Rowan Collins"  wrote in message
news:b3bd7acf-a525-d921-1b1b-64ccf94b8...@gmail.com...
>
>On 02/09/2016 20:32, Davey Shafik wrote:
>> I'd like to introduce a new RFC to deprecate pear/pecl (in 7.2, and
>> remove
>> in 8.0), as well as add composer/pickle (optional in 7.2, default in
>> 7.3+)
>> in their place.
>>
>> https://wiki.php.net/rfc/deprecate-pear-include-composer
>
>Hi Davey,
>
>I think this is a sensible idea. It basically accepts the reality that
PEAR
>is no longer the main place new users of PHP should look for 3rd-party
>code.
>
>Thinking about the responses so far, I thought it would be useful to
>enumerate just what PEAR is, and what is being proposed for removal. It
>might even be worth adding a version of this to the RFC, in case it
reaches
>a wider audience who won't see this discussion.
>
>As I understand it, PEAR is:
>
>A1) A command-line package management tool for installing and updating
>packages of PHP code over the Internet.

Incorrect. There is a web interface which I use EXCLUSIVELY to maintain the
contents of my PEAR library.


You only work in a web interface instead of an editor and version control
system?

PEAR does not have a version control system. My software has an SVN repository, but that is totally unconnected with PEAR. My choice of editor has no bearing on the issue.

I use the web interface to maintain PEAR on my local machine, and my hosting companies provide a web interface in their control panels.


Packagist has a web interface to add new packages. New versions
(maintenance) are published automatically once you push a new version tag.

Any proposed replacement which does not have a
web interface I'm afraid is totally unacceptable. Command line interfaces
went out of fashion when the Windows OS was first released, and anyone who still insists on using one has not joined the rest of the world in the 21st
century.


The Windows OS doesn't even have a built-in SSH client to maintain remote
systems.

Then use 3rd party software. There are several available.

Using a command line interface is much better for mintaining a server. No
web interface I'm aware of can compose different tasks as good as bash with
using pipes to filter, sort, reformat, ...

That may be your personal opinion, but it is not shared by others.

I do NOT want the replacement PEAR library to be mixed in with my
application code.


It's not mixed. Every depenendy has it's very own directory within the
vendor directory.

Pear instead mixes everything together by installing libraries globally.

So what?

Global libraries work for Linux distributions as there's a team behind
carefully watching that things are compatible. But PHP applications are
from different vendors. There's nothing that prevents conflicts.

I do NOT want the replacement PEAR library to update itself in the
background.

Composer doesn't do that.

Then how come I've seen several complaints in various forums about composer updating libraries in the background and screwing things up.

It has to be under MY control or I simply won't install it.


You're in full control. There's even a lock file so everyone installing an
app can install the same version of every depenendy. That way it's way
easier to reproduce bugs locally.

It has to be 100% stable, and I'm not sure that composer/pickle fit the
bill.


I can't talk for pickle as I haven't used it as I usually do not use any
additional extensions or compile them in directly.

But I have never had any issues with the stability of Composer.

There may be a small number


I don't think it's a small number. Almost all projects I know use Composer.

Exactly. Only the projects that YOU know use composer, but what percentage of all the PHP projects in the world does that cover?

The only one I know of that uses Pear is bugs.php.net.

That proves nothing except that your knowledge is very limited.

--
Tony Marston


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to