Hi internals,
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
I highly recommend reading the twitter poll and accompanying thread at
https://twitter.com/dshafik/status/756337267547832320
I believe that pickle solves the issues with regards to pecl, and have run
the idea passed Jordi and Pierre. Both are fine with this RFC. :)
I understand that adding in composer/pickle is just setting us up for
having a future "Deprecate composer/pickle & Replace with foo/bar" RFC, so
I've proposed the voting reflect that some people will just want to
deprecate/remove pear/pecl and not replace them at all.
I'm also proposing voting choices around the optional/default introduction
of composer/pickle.
- Davey
Also, just wanted to say:
As a former fairly major contributor to PEAR (see:
http://pear.php.net/user/davey) I understand that PEAR has a special place
in the heart of many old-school PHP developers — but I believe that the
community has spoken, through lack of action on PEARs part, and the rapid
adoption of composer on the general communities part.
We should probably also have some conversations about actually sunsetting
the PEAR and PECL sites and deprovisioning those resources. But that's a
whole other conversation ;)
- Davey
Hi internals,
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
I highly recommend reading the twitter poll and accompanying thread at
https://twitter.com/dshafik/status/756337267547832320I believe that pickle solves the issues with regards to pecl, and have run
the idea passed Jordi and Pierre. Both are fine with this RFC. :)I understand that adding in composer/pickle is just setting us up for
having a future "Deprecate composer/pickle & Replace with foo/bar" RFC, so
I've proposed the voting reflect that some people will just want to
deprecate/remove pear/pecl and not replace them at all.I'm also proposing voting choices around the optional/default introduction
of composer/pickle.
- Davey
Hi internals,
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
I highly recommend reading the twitter poll and accompanying thread at
https://twitter.com/dshafik/status/756337267547832320I believe that pickle solves the issues with regards to pecl, and have run
the idea passed Jordi and Pierre. Both are fine with this RFC. :)I understand that adding in composer/pickle is just setting us up for
having a future "Deprecate composer/pickle & Replace with foo/bar" RFC, so
I've proposed the voting reflect that some people will just want to
deprecate/remove pear/pecl and not replace them at all.I'm also proposing voting choices around the optional/default introduction
of composer/pickle.
- Davey
Will composer/pickle address the unsolved PHP compatibility issue that
makes pecl a pain following the PHP 7 release?
On Fri, Sep 2, 2016 at 12:57 PM, James Gilliland neclimdul@gmail.com
wrote:
Hi internals,
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
I highly recommend reading the twitter poll and accompanying thread at
https://twitter.com/dshafik/status/756337267547832320I believe that pickle solves the issues with regards to pecl, and have
run
the idea passed Jordi and Pierre. Both are fine with this RFC. :)I understand that adding in composer/pickle is just setting us up for
having a future "Deprecate composer/pickle & Replace with foo/bar" RFC,
so
I've proposed the voting reflect that some people will just want to
deprecate/remove pear/pecl and not replace them at all.I'm also proposing voting choices around the optional/default
introduction
of composer/pickle.
- Davey
Will composer/pickle address the unsolved PHP compatibility issue that
makes pecl a pain following the PHP 7 release?
Which, exactly?
- Davey
- szept. 2. 21:58 ezt írta ("James Gilliland" neclimdul@gmail.com):
Hi internals,
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
I highly recommend reading the twitter poll and accompanying thread at
https://twitter.com/dshafik/status/756337267547832320I believe that pickle solves the issues with regards to pecl, and have
run
the idea passed Jordi and Pierre. Both are fine with this RFC. :)I understand that adding in composer/pickle is just setting us up for
having a future "Deprecate composer/pickle & Replace with foo/bar" RFC,
so
I've proposed the voting reflect that some people will just want to
deprecate/remove pear/pecl and not replace them at all.I'm also proposing voting choices around the optional/default
introduction
of composer/pickle.
- Davey
Will composer/pickle address the unsolved PHP compatibility issue that
makes pecl a pain following the PHP 7 release?
You are probably talking about https://bugs.php.net/bug.php?id=71224.
My understanding is that when fetching the packages from pecl.php.net
pickle would still have the same problem (
https://github.com/FriendsOfPHP/pickle/issues/133) but if pecl authors
start adding composer.json to their repos you can describe the php version
dependency for the given extension on a per tag/version basis.
I still think that it would be worth implementing
https://bugs.php.net/bug.php?id=71224
- szept. 2. 21:58 ezt írta ("James Gilliland" neclimdul@gmail.com):
Hi internals,
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
I highly recommend reading the twitter poll and accompanying thread at
https://twitter.com/dshafik/status/756337267547832320I believe that pickle solves the issues with regards to pecl, and have
run
the idea passed Jordi and Pierre. Both are fine with this RFC. :)I understand that adding in composer/pickle is just setting us up for
having a future "Deprecate composer/pickle & Replace with foo/bar"
RFC, so
I've proposed the voting reflect that some people will just want to
deprecate/remove pear/pecl and not replace them at all.I'm also proposing voting choices around the optional/default
introduction
of composer/pickle.
- Davey
Will composer/pickle address the unsolved PHP compatibility issue that
makes pecl a pain following the PHP 7 release?You are probably talking about https://bugs.php.net/bug.php?id=71224.
My understanding is that when fetching the packages from pecl.php.net
pickle would still have the same problem (
https://github.com/FriendsOfPHP/pickle/issues/133) but if pecl authors
start adding composer.json to their repos you can describe the php version
dependency for the given extension on a per tag/version basis.I still think that it would be worth implementing
https://bugs.php.net/bug.php?id=71224
Accidentally replied directly, different report but same issue
https://pear.php.net/bugs/bug.php?id=21008
Hi Tyrael
You are probably talking about https://bugs.php.net/bug.php?id=71224.
My understanding is that when fetching the packages from pecl.php.net
pickle would still have the same problem (
https://github.com/FriendsOfPHP/pickle/issues/133) but if pecl authors
start adding composer.json to their repos you can describe the php version
dependency for the given extension on a per tag/version basis.I still think that it would be worth implementing
https://bugs.php.net/bug.php?id=71224
One thing we can do for pickle is to automatically add composer.json as
part of pickle web which is a packagist for exts (php and other
implementation). That should not be too hard. At least for the packages
were no json is available.
Also Jordi and I still have to settle the integration part.
Hi internals,
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.
+1
A bunch of years back I tried contributing to a handful of PEAR_Auth
packages and the 'maintainer' rejected them all on the basis of the PEAR
library was mothballed with recommendation to use ZendFrameworks Auth
packages. I know at least where I work we're migrating everything off of
PEAR in deference to community maintained packages in composer.
The only negative I could possibly see is a lack of a central, for lack of
a better term, authority of PHP preferred packages for the multitude of
services PEAR offers. But I don't necessarily see this as a major issue
with the multitude of frameworksµframeworks that modularize all their
bits and places like composer/packagist maintaining a growing list of
packages. I guess PEAR served that purpose years ago in a more isolated
PHP source environment, rather than today where it's heavily tracked and
distributed.
Cheers
Dave
Hi internals,
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
I highly recommend reading the twitter poll and accompanying thread at
https://twitter.com/dshafik/status/756337267547832320I believe that pickle solves the issues with regards to pecl, and have run
the idea passed Jordi and Pierre. Both are fine with this RFC. :)I understand that adding in composer/pickle is just setting us up for
having a future "Deprecate composer/pickle & Replace with foo/bar" RFC, so
I've proposed the voting reflect that some people will just want to
deprecate/remove pear/pecl and not replace them at all.I'm also proposing voting choices around the optional/default introduction
of composer/pickle.
I like the idea, my only concern is that pickle hasn't been committed to
master in many months and the build is listed as failing. In fact the last
release (v0.4 from what I can tell) also shows the build as failing?
- Davey
I'm also proposing voting choices around the optional/default introduction
of composer/pickle.
Is Composer really all there is?
I'm looking at the problems projects like tiki have with trying to keep
composer working in an active project, and other projects have just as
many bug reports of composer having failed again! Keeping the right
combination of versions of third party libraries may be what it is
intended to do, but it does not seem to achieve it.
I make no bones about the fact that I don't like the way composer works,
and warnings about "You are running composer with xdebug enabled. This
has a major impact on runtime performance." Trying to set up an
environment where composer only exists for PHP7 so it does not affect
the legacy systems seems equally problematic. And Packagist has some
many cross competing packages that it does not make providing a set of
'supported' php libraries at all feasible?
I've just tried to get owncloud running again. I had it working fine in
PHP5.3 days, but at some point an upgrade failed and while I managed to
keep it working for a bit, it was not stable. I tries again last year
but it was taking too long, so I switched tack this year, installed
clean from the distribution and while it sort of installed it will not
run and add the very thing I'm trying to restore, the mail package. I
SUSPECT it needs composer somewhere under the hood, but getting white
screen failures and no decent errors it's gone in the bin again.
If composer is to replace PEAR then it needs to be properly supported
INSIDE PHP as PEAR is and give the sort of support that PEAR currently
provides to new users. Linux distributions once again provide their own
views on how to combine composer and the other similar package managers
for javascript, python and the like with their own manager and the
situation is simply a mess! I've half a dozen package managers listed
across the whole web framework base, and composer is not top of the list.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Is Composer really all there is?
I'm looking at the problems projects like tiki have with trying to keep
composer working in an active project, and other projects have just as
many bug reports of composer having failed again! Keeping the right
combination of versions of third party libraries may be what it is
intended to do, but it does not seem to achieve it.
Interesting, can you give any details of these problems? I've always found composer to do its job very well indeed, and have heard nothing but good things about it. I did a quick search for "tiki composer" and found a page with lots of teething problems from 3 years ago, but I suspect many of those are long since fixed. There's some interesting questions around how to use it for optional plugins, which I hadn't thought about before, but PEAR doesn't do anything to help there either, so not really relevant to this discussion.
warnings about "You are running composer with xdebug enabled. This
has a major impact on runtime performance."
So you don't like that the tool defaults to giving you a warning, which can be suppressed, to explain why it might seem slow, due to a debugging tool documented as not being suitable for production because it may have a performance impact? I imagine PEAR runs slower as well, it just doesn't default to telling you so.
Trying to set up an
environment where composer only exists for PHP7 so it does not affect
the legacy systems seems equally problematic.
Do you mean having a single codebase that can be installed with or without composer? Mostly that's just a case of creating alternative autoloader / bootstrap files, since all the code knows about composer at runtime is "require 'vendor/autoload.php';"
And Packagist has some
many cross competing packages that it does not make providing a set of
'supported' php libraries at all feasible?
There is some truth in this, pear.php.net was a curated package library, whereas packagist.org is an open publishing platform. The problem is that for something to be curated somebody has to spend time curating; mostly, the people doing that right now are the big frameworks like Symfony, although there are a few projects like PHP League. The idea behind PHP-FIG is also relevant: rather than PEAR only allowing packages that follow a certain style, users can see on an open market which packages advertise their compatibility.
If composer is to replace PEAR then it needs to be properly supported
INSIDE PHP as PEAR is and give the sort of support that PEAR currently
provides to new users.
What kind of support are we talking about here? My experience of PEAR is "pear install foo" and in composer that would be "composer require somebody/foo", so I'm interested which scenarios you think need extra work.
Regards,
--
Rowan Collins
[IMSoP]
Is Composer really all there is?
I'm looking at the problems projects like tiki have with trying to keep
composer working in an active project, and other projects have just as
many bug reports of composer having failed again! Keeping the right
combination of versions of third party libraries may be what it is
intended to do, but it does not seem to achieve it.Interesting, can you give any details of these problems? I've always found composer to do its job very well indeed, and have heard nothing but good things about it. I did a quick search for "tiki composer" and found a page with lots of teething problems from 3 years ago, but I suspect many of those are long since fixed. There's some interesting questions around how to use it for optional plugins, which I hadn't thought about before, but PEAR doesn't do anything to help there either, so not really relevant to this discussion.
https://sourceforge.net/p/tikiwiki/mailman/message/35331374/
warnings about "You are running composer with xdebug enabled. This
has a major impact on runtime performance."So you don't like that the tool defaults to giving you a warning, which can be suppressed, to explain why it might seem slow, due to a debugging tool documented as not being suitable for production because it may have a performance impact? I imagine PEAR runs slower as well, it just doesn't default to telling you so.
But being able to set up an environment where it is easy to switch tools
on and off is being complicated by having to manage different 'composer'
setups. Something which I don't think it was actually designed to handle?
Trying to set up an
environment where composer only exists for PHP7 so it does not affect
the legacy systems seems equally problematic.Do you mean having a single codebase that can be installed with or without composer? Mostly that's just a case of creating alternative autoloader / bootstrap files, since all the code knows about composer at runtime is "require 'vendor/autoload.php';"
This is perhaps my sticking point. I have a perfectly stable framework
without the need for any 'autoloader', and a folder structure that
works. Reworking the whole framework so that it follows the 'vendor'
rules while still also just working with bog standard require_once in
the right place is where I keep coming unstuck.
And Packagist has some
many cross competing packages that it does not make providing a set of
'supported' php libraries at all feasible?There is some truth in this, pear.php.net was a curated package library, whereas packagist.org is an open publishing platform. The problem is that for something to be curated somebody has to spend time curating; mostly, the people doing that right now are the big frameworks like Symfony, although there are a few projects like PHP League. The idea behind PHP-FIG is also relevant: rather than PEAR only allowing packages that follow a certain style, users can see on an open market which packages advertise their compatibility.
I don't think the current PEAR suite will disappear since it does
provide a clean set of tools, and probably at least 80% of legacy
systems still rely on it. I've just been stung by 'mcrypt' not being
available with a couple of the owncloud alternatives I tried. They will
not install on PHP7, and I think I'm going to have to roll back to
PHP5.x to get that working.
If composer is to replace PEAR then it needs to be properly supported
INSIDE PHP as PEAR is and give the sort of support that PEAR currently
provides to new users.What kind of support are we talking about here? My experience of PEAR is "pear install foo" and in composer that would be "composer require somebody/foo", so I'm interested which scenarios you think need extra work.
I WAS using SUSE's software management to keep all my production
machines working cleanly. Currently that provides 5.6.9 along with every
pear package I use. composer does not figure at all, but node, pip and
bower all get support. Although I get the impression that a combination
of npm with composer may be the way forward. npm can manage the
development dependencies such as css tools as well as javascript
management, but then do I actually need composer as well? Although I
will ALWAYS prefer supplying the distributed library files I need from a
local server rather than assuming they will remain available from some
third party site, and it's that which I can't do with composer?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Interesting, can you give any details of these problems?
https://sourceforge.net/p/tikiwiki/mailman/message/35331374/
Right, so their problem was not with Composer itself, but with Satis,
which is a tool for publishing or mirroring your own packages, like
running your own PEAR channel. They wanted to update it for some reason,
but couldn't because the server had a really old version of PHP, because
it was running a really old version of Ubuntu. Elsewhere in the thread,
they have problems downloading a particular version of a package from
SourceForge. None of this sounds like something that PEAR, or any other
alternative to Composer, would help with.
So you don't like that the tool defaults to giving you a warning,
which can be suppressed, to explain why it might seem slow, due to a
debugging tool documented as not being suitable for production
because it may have a performance impact? I imagine PEAR runs slower
as well, it just doesn't default to telling you so.
But being able to set up an environment where it is easy to switch tools
on and off is being complicated by having to manage different 'composer'
setups. Something which I don't think it was actually designed to handle?
I'm not sure what you mean by that. Composer itself is distributed as a
single PHAR file, and is governed almost entirely by the composer.json
in your project, and pretty much everything can be different in every
project. It's an awful lot easier to have multiple setups of that than
PEAR, which is absolutely designed to manage central system-wide packages.
Do you mean having a single codebase that can be installed with or without composer? Mostly that's just a case of creating alternative autoloader / bootstrap files, since all the code knows about composer at runtime is "require 'vendor/autoload.php';"
This is perhaps my sticking point. I have a perfectly stable framework
without the need for any 'autoloader', and a folder structure that
works. Reworking the whole framework so that it follows the 'vendor'
rules while still also just working with bog standard require_once in
the right place is where I keep coming unstuck.
Right, I remember switching to using an autoloader (long long before
composer existed), and what a relief it was not to have to manage great
lists of require_once everywhere any more. :) I think the only thing we
had to fix was some class names being used as lower-case, when the
filenames that needed including were camel-case. The simplest migration
that occurs to me is "if ( file_exists('vendor/autoload.php') ) {
require_once 'vendor/autoload.php'; } else { /* require all the
individual dependencies as before */ }".
What kind of support are we talking about here? My experience of PEAR is "pear install foo" and in composer that would be "composer require somebody/foo", so I'm interested which scenarios you think need extra work.
I WAS using SUSE's software management to keep all my production
machines working cleanly. Currently that provides 5.6.9 along with every
pear package I use.
OK, so short story: you're not invoking pear directly anyway, so Davey's
proposal to remove it won't actually affect you at all.
Although I will ALWAYS prefer supplying the distributed library files I need from a
local server rather than assuming they will remain available from some
third party site, and it's that which I can't do with composer?
That's pretty much what Satis is for, as mentioned above. Or, if you're
willing to pay, Toran Proxy, which is how Jordi gets the money to
improve Composer.
Regards,
--
Rowan Collins
[IMSoP]
This is perhaps my sticking point. I have a perfectly stable framework
without the need for any 'autoloader', and a folder structure that
works. Reworking the whole framework so that it follows the 'vendor'
rules while still also just working with bog standard require_once in
the right place is where I keep coming unstuck.Right, I remember switching to using an autoloader (long long before
composer existed), and what a relief it was not to have to manage great
lists of require_once everywhere any more. :) I think the only thing we
had to fix was some class names being used as lower-case, when the
filenames that needed including were camel-case. The simplest migration
that occurs to me is "if ( file_exists('vendor/autoload.php') ) {
require_once 'vendor/autoload.php'; } else { /* require all the
individual dependencies as before */ }".
The problem with that 'simple migration' is that currently I have
nothing in the 'vendor/autoload.php' pot and everything in the
'individual dependencies'. I don't recognise the 'manage great lists of
require_once everywhere' simply replacing 'vendor/autoload.php' with
'../kernel/setup_inc.php' to load the framework. Yes the framework is
something of a maze of functions and files, but it only loads a class
when it needs it, and skips those it does not need. 15+ years of
development starting back in PHP4 days. It's reworking 50+ major
packages, pulling out the few files that make up the classes and
repackaging them in 'vendor' format, while still having smarty plugins,
templates, modules, admin tools and the like and managing just what
tools a user has access to based on their role when accessing the site.
In essence the composer setup is user specific if I am going down that
path, and while making everything available and then not allowing access
may be the modern way, only loading the sub-set of packages that the
current job needs seems a lot faster to me. And if the user does not
have access rights at all we only get as far as loading the access
control functions, and throw an error page back.
I do have a few third party elements. Smarty is now 'composer loadable',
but ADOdb is not and has it's own db selected loader. But smarty is
extended with additional local plug-ins so I don't see how there is any
gain moving files around the file system rather than keeping them with
their intended package. And returning to PEAR, if the relevant package
is available, those functions are also switched on, or one falls back to
defaults. The installer advises what it can and can't find, gives
guidance to installing required tools and advise on optional ones.
Something that is easy to do with the PEAR/PECL/dynamic extension system
we currently have, but not so easy to manage with composer? A handler
can obviously be written to edit the composer setup on the fly, and it's
that sort of support I would expect if composer replaces PEAR.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
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.
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.
A2) A curated default "channel" for the package management tool, at
pear.php.net
A3) The coding style guidelines for publishing on that channel
A4) An ecosystem of packages built to those guidelines
While PECL is:
B1) A related command-line tool for managing extensions to PHP itself.
B2) A default channel for the extension management tool, at pecl.php.net
The command-line tools (A1 and B1 above) are currently distributed with
PHP by default, and this is what we are looking to deprecate. Composer
is the common choice to fill the role of A1, and "pickle" is being
proposed as the official replacement for B1. Everything else will still
be there, including the ability to download the tools, probably through
your OS or stack's package management system.
As to the rest, a few rambling thoughts:
-
There is no single replacement for pear.php.net. packagist.org
partially fulfils job A2, but it is a marketplace, not a curated
channel, and it doesn't do anything to standardise style (A3) or
interoperability (A4). PHP-FIG is one attempt to fill that
standardisation; it's entirely voluntary, and entirely separate from
php.net, but it's not like anyone was ever forced to publish on
pear.php.net. -
pear.php.net is technically only one "channel" compatible with the
tool, but I'm not sure how many others are out there in practice. As a
random example, I know that Swift Mailer used to maintain a PEAR
channel, but checking back it is now officially unsupported:
http://pear.swiftmailer.org/ -
On the flip side, many of the packages that are published on
pear.php.net are also available on packagist.org for installation with
composer, either in this list https://packagist.org/packages/pear/ or in
unofficial forks. -
The PEAR coding style would probably be considered "out of date" by a
lot of PHP devs. That's partly a matter of fashion, but also a natural
consequence of it predating certain language features - autoloading,
namespaces, etc - which people want to take advantage of. -
There is a "PEAR2" consisting of the "pyrus" tool, and pear2.php.net.
It appears to be basically abandoned, although it is still prominently
linked from pear.php.net. I assume pyrus never made into the default
distribution of PHP?
Regards,
--
Rowan Collins
[IMSoP]
- The PEAR coding style would probably be considered "out of date" by a
lot of PHP devs. That's partly a matter of fashion, but also a natural
consequence of it predating certain language features - autoloading,
namespaces, etc - which people want to take advantage of.
A starting point for a replacement for PEAR might well be a style guide
that lays out just how one should build a modern suite of code. My
stumbling block deciphering owncloud is just how one does work out
exactly what code has been loaded and from what files. Irrelevant if
things just work, but when debugging an installation, the code flow
should be easy to establish!
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
A starting point for a replacement for PEAR might well be a style guide
that lays out just how one should build a modern suite of code. My
stumbling block deciphering owncloud is just how one does work out
exactly what code has been loaded and from what files. Irrelevant if
things just work, but when debugging an installation, the code flow
should be easy to establish!
As mentioned, that's exactly what PHP-FIG is doing; what you're talking
about is exactly what PSR-1, PSR-2, and PSR-4 describe.
You may not agree with the choices they made, like the people that made
them, or approve of the processes they used, but all that would be just
as likely if they happened to be hosted on a sub-domain of php.net.
Regards,
--
Rowan Collins
[IMSoP]
A starting point for a replacement for PEAR might well be a style guide
that lays out just how one should build a modern suite of code. My
stumbling block deciphering owncloud is just how one does work out
exactly what code has been loaded and from what files. Irrelevant if
things just work, but when debugging an installation, the code flow
should be easy to establish!As mentioned, that's exactly what PHP-FIG is doing; what you're talking
about is exactly what PSR-1, PSR-2, and PSR-4 describe.You may not agree with the choices they made, like the people that made
them, or approve of the processes they used, but all that would be just
as likely if they happened to be hosted on a sub-domain of php.net.
So this RFC is simply proposing that PHP-FIG becomes the standard for
writing PHP code?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
So this RFC is simply proposing that PHP-FIG becomes the standard for
writing PHP code?
No, that is not at all what this RFC is proposing. The RFC is simply
proposing to stop bundling the command-line tool "pear" with default PHP
builds.
The PEAR coding standards will still exist, the packages created
according to them will still be usable, and you'll still be able to
download pear, or pyrus, to access them. You could also use composer to
access most of them, and publish packages adhering to that style on
packagist.org, or pretty much any platform you want.
The only reason I mentioned PHP-FIG is because they are trying to write
a modern standard for writing interoperable PHP libraries, which is what
you asked for.
I guess we could have a philosophical debate about what it means for
something to be "the standard" rather than "a standard", and whether
PEAR was "more official" than PHP-FIG, and just who gets to decide what
PHP is.
But once again, I find myself being drawn into an off-topic debate about
coding styles, and I would like to apologise to Davey as it has nothing
to do with his RFC.
Regards,
--
Rowan Collins
[IMSoP]
On Sat, Sep 3, 2016 at 2:53 PM, Rowan Collins rowan.collins@gmail.com
wrote:
So this RFC is simply proposing that PHP-FIG becomes the standard for
writing PHP code?No, that is not at all what this RFC is proposing. The RFC is simply
proposing to stop bundling the command-line tool "pear" with default PHP
builds.The PEAR coding standards will still exist, the packages created according
to them will still be usable, and you'll still be able to download pear, or
pyrus, to access them. You could also use composer to access most of them,
and publish packages adhering to that style on packagist.org, or pretty
much any platform you want.The only reason I mentioned PHP-FIG is because they are trying to write a
modern standard for writing interoperable PHP libraries, which is what you
asked for.I guess we could have a philosophical debate about what it means for
something to be "the standard" rather than "a standard", and whether PEAR
was "more official" than PHP-FIG, and just who gets to decide what PHP is.But once again, I find myself being drawn into an off-topic debate about
coding styles, and I would like to apologise to Davey as it has nothing to
do with his RFC.
No need to apologize, thank you for defending my idea and so eloquently — I
will amend the RFC with your earlier suggestions; being as I will do so
almost verbatim, would you mind being added as a co-author? I think it's a
substantial contribution :)
- Davey
No need to apologize, thank you for defending my idea and so
eloquently — I will amend the RFC with your earlier suggestions; being
as I will do so almost verbatim, would you mind being added as a
co-author? I think it's a substantial contribution :)
Thanks, I'm just trying to make sure everyone understands the proposal.
Feel free to credit me or not as you see fit. :)
Regards,
--
Rowan Collins
[IMSoP]
I guess we could have a philosophical debate about what it means for
something to be "the standard" rather than "a standard", and whether
PEAR was "more official" than PHP-FIG, and just who gets to decide what
PHP is.But once again, I find myself being drawn into an off-topic debate about
coding styles, and I would like to apologise to Davey as it has nothing
to do with his RFC.
I think that what is missing is a discussion on just where one should
start these days in terms of a basic framework for beginners. That there
are so many competing "standards" that in many cases do not play well
together is MY problem. That my key libraries ARE moving to a different
style and have different ways of loading is a pull one way, and my web
side interface has other loaders handling javascript and css packages
which adds to the complexity.
But perhaps we don't bother about the novice PHP user and just assume
they are all simply using third party frameworks already so all that
needs to be looked at is improving the library/framework developer
experience. It would be nice to get back to some BASIC functionality
such as loading a form, validating it's content, and string the results
without having a dozen ways of filtering the inputs and a dozen ways of
accessing the database.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
I guess we could have a philosophical debate about what it means for
something to be "the standard" rather than "a standard", and whether
PEAR was "more official" than PHP-FIG, and just who gets to decide what
PHP is.But once again, I find myself being drawn into an off-topic debate about
coding styles, and I would like to apologise to Davey as it has nothing
to do with his RFC.I think that what is missing is a discussion on just where one should
start these days in terms of a basic framework for beginners. That there
are so many competing "standards" that in many cases do not play well
together is MY problem. That my key libraries ARE moving to a different
style and have different ways of loading is a pull one way, and my web
side interface has other loaders handling javascript and css packages
which adds to the complexity.But perhaps we don't bother about the novice PHP user and just assume
they are all simply using third party frameworks already so all that
needs to be looked at is improving the library/framework developer
experience. It would be nice to get back to some BASIC functionality
such as loading a form, validating it's content, and string the results
without having a dozen ways of filtering the inputs and a dozen ways of
accessing the database.--
Lester Caine - G8HFLContact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk--
How many competing autoloading standards are there? PSR-0 (PEAR, Zend, etc) and PSR-4 are the two main ones I know of. Symphony used to have their own style back in the day, but swapped to PSR-0 with Symfony2 8? years ago. I suppose you could also work with just a class map, which I've seen some libs use (eg TCPDF)... That said if you've got some other style, just register a loader for it and get on with it. Sounds to me like your problem isn't with Composer per se, but autoloading in general?
Cheers,
David
"Rowan Collins" wrote in message
news:b3bd7acf-a525-d921-1b1b-64ccf94b858b@gmail.com...
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.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. 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.
I do NOT want the replacement PEAR library to be mixed in with my
application code.
I do NOT want the replacement PEAR library to update itself in the
background. It has to be under MY control or I simply won't install it.
It has to be 100% stable, and I'm not sure that composer/pickle fit the
bill.
There may be a small number of developers out there who think that composer
is the best thing since sliced bread, but I'm not one of them, and I
strongly object to a small number of developers having the ability to impose
their personal preferences on the rest of the community.
--
Tony Marston
Tony Marston TonyMarston@hotmail.com schrieb am So., 4. Sep. 2016, 10:38:
"Rowan Collins" wrote in message
news:b3bd7acf-a525-d921-1b1b-64ccf94b858b@gmail.com...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.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?
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.
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, ...
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.
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.
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.
The only one I know of that uses Pear is bugs.php.net.
of developers out there who think that composer
is the best thing since sliced bread, but I'm not one of them, and I
strongly object to a small number of developers having the ability to
impose
their personal preferences on the rest of the community.--
Tony Marston
"Niklas Keller" wrote in message
news:CANUQDCjeH45_2aEq74CCEOY4xc3xJ0o_+yRQ2NVy0K2VdOXFBQ@mail.gmail.com...
Tony Marston TonyMarston@hotmail.com schrieb am So., 4. Sep. 2016, 10:38:
"Rowan Collins" wrote in message
news:b3bd7acf-a525-d921-1b1b-64ccf94b858b@gmail.com...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.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
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.
I would imagine for the same reason Stack Overflow is full of questions about their JS loop not running their PHP properly, or "resource expected, boolean found" errors: they don't understand what they're doing, or haven't read the manual properly.
Composer updates your libraries when you run "composer update", or fetches the latest that you've said are valid if you run "composer install" and don't have a lock file listing which versions you last updated to (i.e. you deleted it or didn't commit it to version control). It updates itself if you run "composer self-update". And that's it, as far as I know; I'm not even sure what it would mean for it to do stuff "in the background", because (much like pear) it's just an admin tool, not something you include at runtime.
Regards,
--
Rowan Collins
[IMSoP]
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.
That proves nothing except that your knowledge is very limited.
indeed it does.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
"Ferenc Kovacs" wrote in message
news:CAH-PCH5qHdYen33Q_s7kTKM_8qK71v8Ky6kT4fzuRfAwfX06BQ@mail.gmail.com...
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.That proves nothing except that your knowledge is very limited.
indeed it does.
I can only report what I have read in various newsgroups and forums, and
they have said that composer has screwed up their installations. If it is
capable of doing that then it is a serious issue that needs addressing.
--
Tony Marston
On Wed, Sep 7, 2016 at 9:49 AM, Tony Marston TonyMarston@hotmail.com
wrote:
"Ferenc Kovacs" wrote in message news:CAH-PCH5qHdYen33Q_s7kTKM_
8qK71v8Ky6kT4fzuRfAwfX06BQ@mail.gmail.com...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.That proves nothing except that your knowledge is very limited.
indeed it does.
I can only report what I have read in various newsgroups and forums, and
they have said that composer has screwed up their installations. If it is
capable of doing that then it is a serious issue that needs addressing.
you can, but you shouldn't spread FUD but do your own research.
composer will only do something when you execute it, without providing any
actual problem, there is no way those could be refuted (FUD), and brings
nothing to the discussion.
what you have probably seen is people not using the tool properly
from my experience people usually screw 2 things up:
- executing "composer update" without any arguments which will update
every package listed in your composer.json file to the latest version
allowed by the version constraints - not putting the composer.lock under version control and then being
surprised that the other developer who makes a "composer install" from
composer.json can have different(eg. more recent) versions installed
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
I can only report what I have read in various newsgroups and forums, and
they have said that composer has screwed up their installations. If it is
capable of doing that then it is a serious issue that needs addressing.you can, but you shouldn't spread FUD but do your own research.
composer will only do something when you execute it, without providing any
actual problem, there is no way those could be refuted (FUD), and brings
nothing to the discussion.
what you have probably seen is people not using the tool properly
from my experience people usually screw 2 things up:
- executing "composer update" without any arguments which will update
every package listed in your composer.json file to the latest version
allowed by the version constraints- not putting the composer.lock under version control and then being
surprised that the other developer who makes a "composer install" from
composer.json can have different(eg. more recent) versions installed
This does highlight the different approach to handling things in a
production environment over a development one. The problems I have seen
IS when composer.lock gets replaced by mistake, or when an update picks
up a change to a package that was not actually the one expected. Running
around then like headless chicks trying to work out what is wrong is
much like the problems when a hosting site simply switches from PHP5.3
to 5.4 without warning.
I can see that composer has a place in a development environment and
developers will be more than happy playing with that, running the right
command line steps and keeping their set of composer controlled
libraries up to date. The problem comes when 'publishing' a version of a
project and ensuring that the production hosting has the right setup.
The web based tools built into a distribution process will need to be
able to educate users who have been happy with PEAR into the new style
of working and it's that layer that needs to be at least prototyped
before current functional systems are switched off.
But I know the answer already ... not our problem :(
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
2016-09-07 11:33 GMT+02:00 Lester Caine lester@lsces.co.uk:
I can only report what I have read in various newsgroups and forums, and
they have said that composer has screwed up their installations. If
it is
capable of doing that then it is a serious issue that needs
addressing.you can, but you shouldn't spread FUD but do your own research.
composer will only do something when you execute it, without providing
any
actual problem, there is no way those could be refuted (FUD), and brings
nothing to the discussion.
what you have probably seen is people not using the tool properly
from my experience people usually screw 2 things up:
- executing "composer update" without any arguments which will update
every package listed in your composer.json file to the latest version
allowed by the version constraints- not putting the composer.lock under version control and then being
surprised that the other developer who makes a "composer install" from
composer.json can have different(eg. more recent) versions installedThis does highlight the different approach to handling things in a
production environment over a development one. The problems I have seen
IS when composer.lock gets replaced by mistake
If someone replaces it by mistake, you should have a version control system
that
allows reverting that change. You're fine then.
or when an update picks
up a change to a package that was not actually the one expected.
If a vendor doesn't follow semver, you can pin specific versions at any
time and only
update the constraint manually and run composer update afterwards.
Running
around then like headless chicks trying to work out what is wrong is
much like the problems when a hosting site simply switches from PHP5.3
to 5.4 without warning.
That's entirely different. If dependencies change, you clearly see a
changed composer.lock
in your version control system history.
I can see that composer has a place in a development environment and
developers will be more than happy playing with that, running the right
command line steps and keeping their set of composer controlled
libraries up to date. The problem comes when 'publishing' a version of a
project and ensuring that the production hosting has the right setup.
If you commit your composer.lock file, composer install will install just
the same dependency
versions you have locally installed on your development system. There's no
difference between
development dependencies and production dependencies, apart from
require-dev, which you might
want to skip on production.
The web based tools built into a distribution process will need to be
able to educate users who have been happy with PEAR into the new style
of working and it's that layer that needs to be at least prototyped
before current functional systems are switched off.
There's a getting started guide and enough documentation available for
Composer.
https://getcomposer.org/
Regards, Niklas
But I know the answer already ... not our problem :(
--
Lester Caine - G8HFLContact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
I can only report what I have read in various newsgroups and forums, and
they have said that composer has screwed up their installations. If it is
capable of doing that then it is a serious issue that needs addressing.
you can, but you shouldn't spread FUD but do your own research.
composer will only do something when you execute it, without providing any
actual problem, there is no way those could be refuted (FUD), and brings
nothing to the discussion.
what you have probably seen is people not using the tool properly
from my experience people usually screw 2 things up:1. executing "composer update" without any arguments which will update every package listed in your composer.json file to the latest version allowed by the version constraints 2. not putting the composer.lock under version control and then being surprised that the other developer who makes a "composer install" from composer.json can have different(eg. more recent) versions installedThis does highlight the different approach to handling things in a
production environment over a development one. The problems I have seen
IS when composer.lock gets replaced by mistake, or when an update picks
up a change to a package that was not actually the one expected. Running
around then like headless chicks trying to work out what is wrong is
much like the problems when a hosting site simply switches from PHP5.3
to 5.4 without warning.
composer.lock is supposed to be version controlled, so figuring out
which package have been updated should not be a problem. besides, if you
don't run "composer install" the package aren't going to be updated. but
when you do, you will see which packages are update.
even if you run "composer update" without an argument, it should only
update packages to "semver compatible" version of those package unless
the version constraints have been manually entered to allow major
version upgrade. obviously some package releases don't respect semver
(either by ignorance/choice or because there is an unknown bug)
if you deploy an updated composer.lock in production and that it
upgrades your dependencies. that means that it passes code review, CI
and staging or that you don't do any of those. I don't think composer
should be blamed for that
I can see that composer has a place in a development environment and
developers will be more than happy playing with that, running the right
command line steps and keeping their set of composer controlled
libraries up to date. The problem comes when 'publishing' a version of a
project and ensuring that the production hosting has the right setup.
The web based tools built into a distribution process will need to be
able to educate users who have been happy with PEAR into the new style
of working and it's that layer that needs to be at least prototyped
before current functional systems are switched off.
"current functional systems are switched off." => this is not what is
being proposed by the rfc!
the first potential vote is "Deprecate pear/pecl & unbundle in 8.0" if
it passes, it means it won't be bundle with PHP and it will probably
stopped being referenced in the documentation. but it will keep working,
that's very different from "switched off"But I know the answer already ... not our problem :(
This does highlight the different approach to handling things in a
production environment over a development one. The problems I have seen
IS when composer.lock gets replaced by mistake, or when an update picks
up a change to a package that was not actually the one expected. Running
around then like headless chicks trying to work out what is wrong is
much like the problems when a hosting site simply switches from PHP5.3
to 5.4 without warning.
How is this any different from PEAR, or any other package or dependency
management system? Managing the versions of shared libraries is a
notoriously difficult problem - ever hear of "DLL hell"?
If anything, the Composer approach is simpler to deploy, because you can
create a tar ball of the whole project with a populated vendor
directory, and copy it straight to production. (I believe that's
possible with PEAR, too, but not when using the standard shared-library
configuration.) Or you can copy the composer.lock file (probably by
committing to version control) and run "composer install" and get the
same versions you had before without needing to manually go through a
deployment checklist.
I think the bigger difference is in the style - and number - of
dependencies people are pulling in. PEAR packages, in my experience,
have a very strict compatibility policy, and most are at this point very
stable simply because they're not at the cutting edge of development. So
setting up a production server with a slightly different version of
Cache_Lite is unlikely to cause that many problems.
The problems come when you're composing your application out of many
dozens of small libraries, all actively developed, and some not being as
careful as they should with stability. That's not Composer's fault, and
if running your own PEAR channel was still common, you'd get the same thing.
Regards,
Rowan Collins
[IMSoP]
If anything, the Composer approach is simpler to deploy, because you can
create a tar ball of the whole project with a populated vendor
directory, and copy it straight to production. (I believe that's
possible with PEAR, too, but not when using the standard shared-library
configuration.) Or you can copy the composer.lock file (probably by
committing to version control) and run "composer install" and get the
same versions you had before without needing to manually go through a
deployment checklist.
I'm still supporting 15+ year old systems and the user manuals are
second nature to the users. Changing things requires people to adapt to
the change and even subtle changes like run "composer install" can be a
problem. Yes we can package everything together, but historically
different sites have opted for different options and I doubt that two
sites are now using the same set of tools in the background. We can
continue to make PEAR work as an option but that means maintaining code
that others are improving via different programming styles.
This comes down simply to 'education', and just as we provide migration
guides to check deprecated code and help re-write it there needs to be
the same sort of guideline - provided by PHP - as to how composer or
what ever can be used to replace the previous processes. I've seen
several examples of how I could be using it, but none that dovetail in
with what I have.
People who already know composer, as perhaps it's all they have ever
used, are at an advantage. I've tried a couple of times to pick up a
library that NOW has a composer option, Smarty is a case in point, but
IT'S use of composer forces changes to the style of working that are
then at odds with the rest of the framework. Yes over a few years I can
probably migrate, but this change is adding yet another layer of options
without any regard to interoperability. I can't apply a simple set of
rules and switch style as everybody else has their own style of using
composer? :(
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
People who already know composer, as perhaps it's all they have ever
used, are at an advantage. I've tried a couple of times to pick up a
library that NOW has a composer option, Smarty is a case in point, but
IT'S use of composer forces changes to the style of working that are
then at odds with the rest of the framework. Yes over a few years I can
probably migrate, but this change is adding yet another layer of options
without any regard to interoperability. I can't apply a simple set of
rules and switch style as everybody else has their own style of using
composer? :(
One point, pickle does not need composer to run.
pickle install memcache will install the memcache extension (windows
binaries, from pecl.php.net, etc) straight away.
The composer integration allows to add extension dependencies and
install them in one go using a composer install (or update).
Also I have to state my opinion on this RFC. I am fine with any
outcome. It would be nice to have for the extensions install
especially as pecl does not support binaries nor VCS or any non
pecl.php.net srcs (but downloaded.tgz).Both pickle and composer won't
be more or less successful if they are or not part of the PHP
releases.
Also both pickle and composer are tools that can be used with PHP,
HHVM or future compatible php implementations. They are not part of
the php.net projects and will most likely never be. I also do not
consider pecl.php.net as the main place where users can find
extensions but github and in some extends bitbuckets. This is why I
created pickle in the 1st place, to be able to do pickle install <some
repo>/tag/whatever. The upcoming pickle packagist will simply the
packagist.org pendant for PHP/HHVM/etc extensions, without any kind of
releases being available but using the respective services.
Install/Update can then either use the provided archives (they all
provide archives) or install/update straight from git/svn or even cvs
if some of us still have that internally.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
One point, pickle does not need composer to run.
pickle install memcache will install the memcache extension (windows
binaries, from pecl.php.net, etc) straight away.
That one is useful to know. I have all my own active pear stuff under
the code repository and so plain PEAR is less of a problem other than
where it's hard coded into legacy installers. And I will just need to
manually add it if needed. Windows extensions are the area where I've
not been able to build my own or some time because I need a clean build
system working on W10, which is part of the reason I am concerned if the
likes of interbase is no longer available pre-compiled. I have no
problem playing on Linux, it's just keeping windows clients alive and
the existing set-up just works.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
One point, pickle does not need composer to run.
pickle install memcache will install the memcache extension (windows
binaries, from pecl.php.net, etc) straight away.That one is useful to know. I have all my own active pear stuff under
the code repository and so plain PEAR is less of a problem other than
where it's hard coded into legacy installers. And I will just need to
manually add it if needed. Windows extensions are the area where I've
not been able to build my own or some time because I need a clean build
system working on W10, which is part of the reason I am concerned if the
likes of interbase is no longer available pre-compiled. I have no
problem playing on Linux, it's just keeping windows clients alive and
the existing set-up just works.
The service we provide to build binaries for pecl.php.net remains and will
as long as pecl.php.net is up and running (and it is going to be for a very
long time).
We simply extend this service to the growing amount of extensions only
available on GitHub&co.
This comes down simply to 'education', and just as we provide migration
guides to check deprecated code and help re-write it there needs to be
the same sort of guideline - provided by PHP - as to how composer or
what ever can be used to replace the previous processes. I've seen
several examples of how I could be using it, but none that dovetail in
with what I have.
I guess "we", i.e. PHP, should provide migration guides from ways of
working which we documented in the first place. So is there a document
that describes your current way of working, that you are trying to
migrate from? It's hard to know where to begin when you talk about "a
style of working".
Regards,
Rowan Collins
[IMSoP]
This comes down simply to 'education', and just as we provide migration
guides to check deprecated code and help re-write it there needs to be
the same sort of guideline - provided by PHP - as to how composer or
what ever can be used to replace the previous processes. I've seen
several examples of how I could be using it, but none that dovetail in
with what I have.I guess "we", i.e. PHP, should provide migration guides from ways of
working which we documented in the first place. So is there a document
that describes your current way of working, that you are trying to
migrate from? It's hard to know where to begin when you talk about "a
style of working".
This is the main problem with PHP today. It is SO flexible that there
are probably a dozen ways to do the same thing and all are correct. I
keep being told my way of working is 'old fashioned', but there is no
single path to modernise code which is still working perfectly well on
PHP7. I would appreciate some critique on what would be the right way to
make a large modular set of code into something that conforms better
with a current style of working. I still use multiple files as entry
points stored in folders for each package as that move many years ago
made adding or tailoring functionality an lot easy operation which the
'centralised' code it was developed from made impossible. Namespace
should simply dovetail in to this format, but like other new features
that is not proving advantageous. I'm currently reworking a package for
a new application and can develop it using tools already built into the
framework without needing to change style.
If I was advising a newcomer today what is the best way of starting,
just WHERE would one direct them? Many example are still using mysql and
PHP4 style layouts. What is a good example of a modern PHP application?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
"Ferenc Kovacs" wrote in message
news:CAH-PCH568TPsztkWT553QVQy7jsp1tcqT5w+OT1PoCDt-PbUOg@mail.gmail.com...
On Wed, Sep 7, 2016 at 9:49 AM, Tony Marston TonyMarston@hotmail.com
wrote:"Ferenc Kovacs" wrote in message news:CAH-PCH5qHdYen33Q_s7kTKM_
8qK71v8Ky6kT4fzuRfAwfX06BQ@mail.gmail.com...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.That proves nothing except that your knowledge is very limited.
indeed it does.
I can only report what I have read in various newsgroups and forums, and
they have said that composer has screwed up their installations. If it is
capable of doing that then it is a serious issue that needs addressing.you can, but you shouldn't spread FUD but do your own research.
composer will only do something when you execute it, without providing any
actual problem, there is no way those could be refuted (FUD), and brings
nothing to the discussion.
what you have probably seen is people not using the tool properly
from my experience people usually screw 2 things up:
- executing "composer update" without any arguments which will update
every package listed in your composer.json file to the latest version
allowed by the version constraints- not putting the composer.lock under version control and then being
surprised that the other developer who makes a "composer install" from
composer.json can have different(eg. more recent) versions installed
Perhaps users could be prevented from making such basic mistakes if they had
a 21st century web interface instead of the archaic command line.
--
Tony Marston
On Thu, Sep 8, 2016 at 9:43 AM, Tony Marston TonyMarston@hotmail.com
wrote:
"Ferenc Kovacs" wrote in message news:CAH-PCH568TPsztkWT553QVQy
7jsp1tcqT5w+OT1PoCDt-PbUOg@mail.gmail.com...On Wed, Sep 7, 2016 at 9:49 AM, Tony Marston TonyMarston@hotmail.com
wrote:"Ferenc Kovacs" wrote in message news:CAH-PCH5qHdYen33Q_s7kTKM_
8qK71v8Ky6kT4fzuRfAwfX06BQ@mail.gmail.com...
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.That proves nothing except that your knowledge is very limited.
indeed it does.
I can only report what I have read in various newsgroups and forums, and
they have said that composer has screwed up their installations. If it is
capable of doing that then it is a serious issue that needs addressing.you can, but you shouldn't spread FUD but do your own research.
composer will only do something when you execute it, without providing any
actual problem, there is no way those could be refuted (FUD), and brings
nothing to the discussion.
what you have probably seen is people not using the tool properly
from my experience people usually screw 2 things up:
- executing "composer update" without any arguments which will update
every package listed in your composer.json file to the latest version
allowed by the version constraints- not putting the composer.lock under version control and then being
surprised that the other developer who makes a "composer install" from
composer.json can have different(eg. more recent) versions installedPerhaps users could be prevented from making such basic mistakes if they
had a 21st century web interface instead of the archaic command line.
perhaps, or perhaps they would misclick, but now you are again trying to
divert the discussion from actual problems to the land of FUD.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Perhaps users could be prevented from making such basic mistakes if they
had
a 21st century web interface instead of the archaic command line.
Why don't you make one?
--
Daniel Morris
daniel@honestempire.com
On Thu, Sep 8, 2016 at 4:27 AM, Daniel Morris daniel@honestempire.com
wrote:
Perhaps users could be prevented from making such basic mistakes if they
had
a 21st century web interface instead of the archaic command line.Why don't you make one?
Because that might take real skill that Tony doesn't have? Google "Tony
Marston php" sometime. He's a troll with a very long history. I'm frankly
surprised he hasn't earned a list ban here yet.
--
Daniel Morris
daniel@honestempire.com
On Thu, Sep 8, 2016 at 4:27 AM, Daniel Morris daniel@honestempire.com
wrote:Perhaps users could be prevented from making such basic mistakes if
they
had
a 21st century web interface instead of the archaic command line.Why don't you make one?
Because that might take real skill that Tony doesn't have?
Please refrain from personal attacks on this list.
- Davey
Hi Tony,
"Niklas Keller" wrote in message
news:CANUQDCjeH45_2aEq74CCEOY4xc3xJ0o_+yRQ2NVy0K2VdOXFBQ@mail.gmail.com...Tony Marston TonyMarston@hotmail.com schrieb am So., 4. Sep. 2016,
10:38:"Rowan Collins" wrote in message
news:b3bd7acf-a525-d921-1b1b-64ccf94b858b@gmail.com...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.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.
It has, whether you need it or not is not really relevant to this discussion.
I use the web interface to maintain PEAR on my local machine, and my hosting
companies provide a web interface in their control panels.
Happy to see there are still users for this tool, Christian and I had
good fun writing it. Also you should know that this package is dead,
it has no acttve maintainer (I was the last one) and has some
limitations from to begin with, also was very handy at time especially
for shared hosting without shell access.
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.
Your argument about GUI vs shell is totally irrelevant to this discussion.
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.
Again irrelevant and a wrong one. 95% of the web is run with systems
with shell only access, if at all. And yes, even recent windows
servers do that as well. However, whether you (I think it is fair to
say you can speak for yourself) like it or not (or anyone else) is not
relevant to this discussion.
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.
Composer does not update libraries in the background, your project
dependencies being updated and you running composer update will update
them.
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?
Saying that even Wordpress is starting to implement composer support
says all I have to say about "usage".
The only one I know of that uses Pear is bugs.php.net.
That proves nothing except that your knowledge is very limited.
I admire your enthusiasms but I strongly recommend to soften your tone.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
"Pierre Joye" wrote in message
news:CAEZPtU6aHYb9HsNXbXWp9q9PMoLYiJp=N1rjmspoFmHBEbDHxg@mail.gmail.com...
Hi Tony,
On Tue, Sep 6, 2016 at 2:17 PM, Tony Marston TonyMarston@hotmail.com
wrote:"Niklas Keller" wrote in message
news:CANUQDCjeH45_2aEq74CCEOY4xc3xJ0o_+yRQ2NVy0K2VdOXFBQ@mail.gmail.com...Tony Marston TonyMarston@hotmail.com schrieb am So., 4. Sep. 2016,
10:38:"Rowan Collins" wrote in message
news:b3bd7acf-a525-d921-1b1b-64ccf94b858b@gmail.com...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.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.It has, whether you need it or not is not really relevant to this
discussion.I use the web interface to maintain PEAR on my local machine, and my
hosting
companies provide a web interface in their control panels.Happy to see there are still users for this tool, Christian and I had
good fun writing it. Also you should know that this package is dead,
it has no acttve maintainer (I was the last one) and has some
limitations from to begin with, also was very handy at time especially
for shared hosting without shell access.
Typical. You create a useful tool, get your users hooked, then walk away and
leave them dangling.
--
Tony Marston
On Wed, Sep 7, 2016 at 3:52 AM, Tony Marston TonyMarston@hotmail.com
wrote:
Typical. You create a useful tool, get your users hooked, then walk away
and leave them dangling.
No one owes you anything. You aren't entitled to get free updates to a free
tool. If the author wants to move onto other projects, that's their
prerogative. Stop with the bombastic and abusive tone towards everyone,
particularly the developers, on this list.
"Michael Morris" wrote in message
news:CAEUnE0dfjJ02g2Rhkp9WvnkSXpoLzjK=TMiVDBSuCccgxW2mBw@mail.gmail.com...
On Wed, Sep 7, 2016 at 3:52 AM, Tony Marston TonyMarston@hotmail.com
wrote:Typical. You create a useful tool, get your users hooked, then walk away
and leave them dangling.No one owes you anything. You aren't entitled to get free updates to a free
tool. If the author wants to move onto other projects, that's their
prerogative. Stop with the bombastic and abusive tone towards everyone,
particularly the developers, on this list.
Please point out to me any words I have used which a reasonable person would
class as "abusive". You may not like what I have to say, but I have the
right to say it. I do not like what is being proposed in this RFC, and I
have the right to voice my objections.
There should be a rule that nothing can be deprecated unless there is a
viable, stable, fully functioning and fully supported alternative. I do not
like the way that some people simply say "I do not like this. I do not use
this. Nobody should be using this. Let's deprecate it"
--
Tony Marston
On Thu, Sep 8, 2016 at 9:49 AM, Tony Marston TonyMarston@hotmail.com
wrote:
"Michael Morris" wrote in message news:CAEUnE0dfjJ02g2Rhkp9WvnkS
XpoLzjK=TMiVDBSuCccgxW2mBw@mail.gmail.com...On Wed, Sep 7, 2016 at 3:52 AM, Tony Marston TonyMarston@hotmail.com
wrote:Typical. You create a useful tool, get your users hooked, then walk away
and leave them dangling.No one owes you anything. You aren't entitled to get free updates to a
free
tool. If the author wants to move onto other projects, that's their
prerogative. Stop with the bombastic and abusive tone towards everyone,
particularly the developers, on this list.Please point out to me any words I have used which a reasonable person
would class as "abusive".
"Incorrect. There is a web interface which I use EXCLUSIVELY to maintain
the contents of my PEAR library. 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."
you inject your subjective opinion/anecdotal evidence as an objective fact
and trying to kill the discussion instead of contributing to it.
as you mentioned there is a pear package which provides a web interface for
managing pear packages, but that isn't part of the pear core and hence not
bundled by the php project atm, so I don't think that it is a valid
argument for requiring to bundle a gui interface for composer. if people
need a web interface there will be a web interface (maybe there is one
already: https://github.com/composer-ui/composer-ui ) which they can
install via composer.
"Just because SOME people still like using a command line interface does
not mean that they can force everyone else to use it. If any piece of 21st
century does not come with a web/GUI interface it just shows that the
author is still living in the past and is incapable of serving the needs of
today's users."
first you are arguing in bad faith (eg. that anybody/everybody here is
trying to sabotage those who would prefer a gui over a command line), then
you start namecalling those who would prefer command line over gui (which
is btw. plain wrong in the age of configuration management and immutable
deployment where being able to have automated and reproducible deployments
is a key)
"Typical. You create a useful tool, get your users hooked, then walk away
and leave them dangling."
bad faith and passive aggressive comment.
"Perhaps users could be prevented from making such basic mistakes if they
had a 21st century web interface instead of the archaic command line."
I've replied to this already, but yet another passive aggressive remark
which adds little to nothing to the discussion.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi!
There should be a rule that nothing can be deprecated unless there is a
viable, stable, fully functioning and fully supported alternative. I do
not like the way that some people simply say "I do not like this. I do
not use this. Nobody should be using this. Let's deprecate it"
You can have any rules you like, but if the original author is not
interested in the tool anymore, the only options you have are:
- Support it yourself
- Pay/beg/bribe/persuade somebody to do it for you
- Failing that, use it unsupported or switch to another tool
That's not only how the open source works, that's how everything works -
try to get support for out-of-support commercial software (or
out-of-support hardware for that matter) and see if it's any easier.
So yes, it is "typical" as you note - as typical as the life can be :)
That said, if the tool is useful and being used, I completely agree that
we should make effort in keeping it supported. But we should also
account for the possibility of that effort not being successful.
Stas Malyshev
smalyshev@gmail.com
hi Tony,
"Pierre Joye" wrote in message
news:CAEZPtU6aHYb9HsNXbXWp9q9PMoLYiJp=N1rjmspoFmHBEbDHxg@mail.gmail.com...
Happy to see there are still users for this tool, Christian and I had
good fun writing it. Also you should know that this package is dead,
it has no acttve maintainer (I was the last one) and has some
limitations from to begin with, also was very handy at time especially
for shared hosting without shell access.Typical. You create a useful tool, get your users hooked, then walk away and
leave them dangling.
Ok. You seem to misunderstand the last part of my message. So let me
be crystal clear here. Your attitude right now is poisonous, at best.
Please change it.
Now about this specific comment.
I maintained the core of pear, pear.php.net, pear web frontend along
many other things around pear for years. At some points I was more
busy with php core itself along many other things and also realize
that the PEAR project did not match my expectations nor I see it as
the future of packages/distributions tool for PHP. So I decided that
it is better for my personal, egoistical goals and expectations to
leave the project. How did I left? It took months. I ensured that any
of my packages have maintainers, I ensured that any of the core
components had maintainers, then I left.
So please, before you go down your big horse to insult my work and the
community, do your homework and respect everyone here providing you
the tools and language you use for your own projects. Also I strongly
suggest you to consider your own view or vision as one along many, not
the only viable absolute truth or usage. Thanks.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
"Pierre Joye" wrote in message
news:CAEZPtU4TwuaP1xJx+z_n+Sgj1UjPTYn8pJ5xuvMjei2dke0gJg@mail.gmail.com...
hi Tony,
On Wed, Sep 7, 2016 at 2:52 PM, Tony Marston TonyMarston@hotmail.com
wrote:"Pierre Joye" wrote in message
news:CAEZPtU6aHYb9HsNXbXWp9q9PMoLYiJp=N1rjmspoFmHBEbDHxg@mail.gmail.com...Happy to see there are still users for this tool, Christian and I had
good fun writing it. Also you should know that this package is dead,
it has no acttve maintainer (I was the last one) and has some
limitations from to begin with, also was very handy at time especially
for shared hosting without shell access.Typical. You create a useful tool, get your users hooked, then walk away
and
leave them dangling.Ok. You seem to misunderstand the last part of my message. So let me
be crystal clear here. Your attitude right now is poisonous, at best.
Please change it.
You may not like my attitude, but I am expressing myself without using
abusive terms. I am simply expressing my displeasure with this RFC using
civil, polite and non-abusive terminology. If you don't like my expressions
of disapproval then don't try to bully me into submission as that simply
will not work.
<snip> > >So please, before you go down your big horse to insult my work and the >community,Now about this specific comment.
I did not insult your work as I have been using it for many years. What I
find frustrating is that problems sometimes arise with a new PHP version,
and nobody seems to be maintaining it. I have recently upgraded of my PCs to
PHP7 and I had no end of problems. I had to debug and fix every error
myself, but now I have the PEAR web interface up and running.
do your homework and respect everyone here providing you
the tools and language you use for your own projects. Also I strongly
suggest you to consider your own view or vision as one along many, not
the only viable absolute truth or usage. Thanks.
Then I suggest that you learn to respect your users. There are huge numbers
of developers out there who use PEAR, and they find a web interface more
usable than the archaic command line. If you (and by "you" I mean everyone
who works on PHP internals) wish to deprecate PEAR then you must first
provide a viable alternative - with a web interface - and wait until it has
become stable and been accepted by the community BEFORE you do so. Anything
else would be less than professional.
--
Tony Marston
I had to debug and fix every error myself, but now I have the PEAR web
interface up and running.
Have you contributed these patches back to the community for others to
benefit from? Perhaps you could adopt the maintainerless package yourself?
There are huge numbers of developers out there who use PEAR
Then perhaps as well as taking on the maintainership of
PEAR_Frontend_Web, you could reach out to some of these people and
rekindle the PEAR community.
According to its constitution, it is run by an elected "PEAR Group" and
"President". Since these are elected for fixed terms, the posts have
apparently been vacant since Jun 15th, 2010. [http://pear.php.net/group/]
(and by "you" I mean everyone who works on PHP internals)
Then that should not be "you", but "we" - take some responsibility, and
talk about what you would like to offer the community, rather than what
you demand of it.
Regards,
Rowan Collins
[IMSoP]
"Pierre Joye" wrote in message
news:CAEZPtU4TwuaP1xJx+z_n+Sgj1UjPTYn8pJ5xuvMjei2dke0gJg@mail.gmail.com...hi Tony,
On Wed, Sep 7, 2016 at 2:52 PM, Tony Marston
TonyMarston@hotmail.com wrote:"Pierre Joye" wrote in message
news:CAEZPtU6aHYb9HsNXbXWp9q9PMoLYiJp=N1rjmspoFmHBEbDHxg@mail.gmail.com...Happy to see there are still users for this tool, Christian and I had
good fun writing it. Also you should know that this package is dead,
it has no acttve maintainer (I was the last one) and has some
limitations from to begin with, also was very handy at time especially
for shared hosting without shell access.Typical. You create a useful tool, get your users hooked, then walk
away and
leave them dangling.Ok. You seem to misunderstand the last part of my message. So let me
be crystal clear here. Your attitude right now is poisonous, at best.
Please change it.You may not like my attitude, but I am expressing myself without using
abusive terms. I am simply expressing my displeasure with this RFC
using civil, polite and non-abusive terminology. If you don't like my
expressions of disapproval then don't try to bully me into submission
as that simply will not work.<snip> > > So please, before you go down your big horse to insult my work and the > community,Now about this specific comment.
I did not insult your work as I have been using it for many years.
What I find frustrating is that problems sometimes arise with a new
PHP version, and nobody seems to be maintaining it. I have recently
upgraded of my PCs to PHP7 and I had no end of problems. I had to
debug and fix every error myself, but now I have the PEAR web
interface up and running.do your homework and respect everyone here providing you
the tools and language you use for your own projects. Also I strongly
suggest you to consider your own view or vision as one along many, not
the only viable absolute truth or usage. Thanks.Then I suggest that you learn to respect your users. There are huge
numbers of developers out there who use PEAR, and they find a web
interface more usable than the archaic command line. If you (and by
"you" I mean everyone who works on PHP internals) wish to deprecate
PEAR then you must first provide a viable alternative - with a web
interface - and wait until it has become stable and been accepted by
the community BEFORE you do so. Anything else would be less than
professional.
nobody must provide a viable alternative. But providing an alternative
is the subject of this rf. so maybe php is respecting its users. also
remember that this "Request for Comments" is "Under Discussion". you're
opinion on the rfc is valued, the tone you are using and what you are
implying are a bit less welcomed
regarding the rfc, even if it where to be accepted as-is, you could
still use pear/pecl and its web interface. it just wouldn't be the
recommended way to install package & extensions and it wouldn't be
bundled with php 8. you'll have to install it manually if you are
installing php from source, or as usual with your distribution package
manager otherwise
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.
Do you mean there's an HTML control panel for installing and removing
PEAR packages from a server? I wasn't aware of that, and would be happy
to add it as an additional point in list A. Could you post a link to the
documentation for it?
Is it currently bundled with the official php.net releases? If so, then
we should look into how widely used it is. If not, it is in the same
category as pear.php.net, the coding style, and the libraries already
written, i.e. it won't actually be affected by this RFC at all.
Incidentally, it's tricky to do the same thing with Composer, because
it's mostly built around the idea of the dependencies as part of the
code, i.e. separate for each project, rather than as part of the server
setup. However, you can use it to install packages to a global shared
path, I believe, so if there was interest, somebody could make a UI for
doing that.
Regards,
--
Rowan Collins
[IMSoP]
"Rowan Collins" wrote in message
news:be378f46-9a69-55e5-7e2f-48dfbfd8b1f3@gmail.com...
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.Do you mean there's an HTML control panel for installing and removing PEAR
packages from a server? I wasn't aware of that, and would be happy to add
it as an additional point in list A. Could you post a link to the
documentation for it?
"Rowan Collins" wrote in message
news:be378f46-9a69-55e5-7e2f-48dfbfd8b1f3@gmail.com...
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.Do you mean there's an HTML control panel for installing and removing PEAR
packages from a server? I wasn't aware of that, and would be happy to add
it as an additional point in list A. Could you post a link to the
documentation for it?
The package name is PEAR_Frontend_Web. It is documented at
http://pear.php.net/reference/PEAR_Frontend_Web-latest/
--
Tony Marston
The package name is PEAR_Frontend_Web. It is documented at
http://pear.php.net/reference/PEAR_Frontend_Web-latest/
Thanks, if that's bundled with PHP (i.e. you don't need to run "pear install PEAR_Frontend_Web" to find it) then that should definitely be added to the list in the RFC.
--
Rowan Collins
[IMSoP]
Hi!
Incorrect. There is a web interface which I use EXCLUSIVELY to maintain
the contents of my PEAR library. 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.
Err, no. Command line is as alive in 21th century as it was in 20th.
Which Microsoft fully recognizes finally now that they made their shell
as powerful as other shells has been instead of a sorry excuse for a
shell they had for years.
I do NOT want the replacement PEAR library to update itself in the
background. It has to be under MY control or I simply won't install it.
That is valid concern, nothing in the library system should do anything
"on background" without an explicit command. But I don't think composer
actually does that unless you ask it to?
Stas Malyshev
smalyshev@gmail.com
"Stanislav Malyshev" wrote in message
news:1aad32b9-8481-2fb4-4912-66705bd59e57@gmail.com...
Hi!
Incorrect. There is a web interface which I use EXCLUSIVELY to maintain
the contents of my PEAR library. 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.Err, no. Command line is as alive in 21th century as it was in 20th.
Which Microsoft fully recognizes finally now that they made their shell
as powerful as other shells has been instead of a sorry excuse for a
shell they had for years.
Just because SOME people still like using a command line interface does not
mean that they can force everyone else to use it. If any piece of 21st
century does not come with a web/GUI interface it just shows that the author
is still living in the past and is incapable of serving the needs of today's
users.
--
Tony Marston
Hi!
Just because SOME people still like using a command line interface does
not mean that they can force everyone else to use it. If any piece of
Nobody is forcing you to use anything.
21st century does not come with a web/GUI interface it just shows that
the author is still living in the past and is incapable of serving the
needs of today's users.
Well, since PHP is an example of such software, I guess we should close
the shop and go home. Or, alternatively, grandiose avoid blanket
statements and instead discuss things at appropriate technological
level. PHP has a large set of command-line tools and will continue to
have it.
Stas Malyshev
smalyshev@gmail.com
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.
+1
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi internals,
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
I highly recommend reading the twitter poll and accompanying thread at
https://twitter.com/dshafik/status/756337267547832320I believe that pickle solves the issues with regards to pecl, and have run
the idea passed Jordi and Pierre. Both are fine with this RFC. :)I understand that adding in composer/pickle is just setting us up for
having a future "Deprecate composer/pickle & Replace with foo/bar" RFC, so
I've proposed the voting reflect that some people will just want to
deprecate/remove pear/pecl and not replace them at all.I'm also proposing voting choices around the optional/default introduction
of composer/pickle.
- Davey
Clearly +1
--
Richard "Fleshgrinder" Fussenegger
I believe that pickle solves the issues with regards to pecl, and have run
the idea passed Jordi and Pierre. Both are fine with this RFC. :)I understand that adding in composer/pickle is just setting us up for
having a future "Deprecate composer/pickle & Replace with foo/bar" RFC, so
I've proposed the voting reflect that some people will just want to
deprecate/remove pear/pecl and not replace them at all.I'm also proposing voting choices around the optional/default introduction
of composer/pickle.
I'm -1 on bundling composer and/or pickle. If people want this software it
is trivial to obtain, and is far easier to keep up to date if it is managed
out of band.
Hi internals,
I'd like to introduce a new RFC to deprecate pear/pecl (in 7.2, and remove
in 8.0),
Yes!
It's good for the software (and its users) if it is maintained and
contributed to using currently_prevailing_conventions in f/oss.
as well as add composer/pickle (optional in 7.2, default in 7.3+)
in their place.
Not so sure about this.
While composer seems to be the currently prevailing convention for PHP
deps right now (I don't know pickle), each project could instead have
its own installation guide containing whatever makes sense (perhaps even
something Windows-based for Tony).
The PHP project could usefully maintain a policy on installation for the
projects it has fingers in (PHP's a style guide to installation guides).
But I don't think it helps to dictate those tools and methods and tie
them to PHP releases. Just liberate the code and encourage uniform
practices but let them evolve with some autonomy.
Tom
Hi!
I'd like to introduce a new RFC to deprecate pear/pecl (in 7.2, and remove
What would be achieved by this? I'm not sure about status of PEAR -
frankly, didn't touch it for a long time - but if composer replaces most
of it, it may be ok to remove by-default install of pear tools. Though
I'm really not sure what "deprecating" means and what it's going to
achieve.
Pickle main README says:
Pickle is a new PHP extension installer. It is based on Composer and the
plan is to get Composer to fully support it.
How is that plan going? I see the pull req it refers to still open,
which means it is still not complete. Should it be completed before we
recommend it as an only solution?
in 8.0), as well as add composer/pickle (optional in 7.2, default in 7.3+)
in their place.
Add in which meaning? Distribute composer package with PHP source?
Wouldn't that add maintenance load to keep it up-to-date?
If that means get some way to d/l newest stable composer, e.g. when
installing php, that probably would be a great idea. Does not require
removing stuff though.
--
Stas Malyshev
smalyshev@gmail.com
Hi!
I'd like to introduce a new RFC to deprecate pear/pecl (in 7.2, and remove
What would be achieved by this? I'm not sure about status of PEAR -
frankly, didn't touch it for a long time - but if composer replaces most
of it, it may be ok to remove by-default install of pear tools. Though
I'm really not sure what "deprecating" means and what it's going to
achieve.Pickle main README says:
Pickle is a new PHP extension installer. It is based on Composer and the
plan is to get Composer to fully support it.How is that plan going? I see the pull req it refers to still open,
which means it is still not complete. Should it be completed before we
recommend it as an only solution?in 8.0), as well as add composer/pickle (optional in 7.2, default in 7.3+)
in their place.Add in which meaning? Distribute composer package with PHP source?
Wouldn't that add maintenance load to keep it up-to-date?If that means get some way to d/l newest stable composer, e.g. when
installing php, that probably would be a great idea. Does not require
removing stuff though.--
Stas Malyshev
smalyshev@gmail.com--
I think there is value in reducing the number of ‘bundled’ things, particularly given that Debian (and thus Ubuntu), Centos and OS X all distribute PEAR/PECL as a separate package. On the Linux distro's it’s a separate (but possibly “recommended” by php-cli etc) package. On OSX there is /usr/lib/install-pear-nozlib.phar.
Unbundling from PHP itself then makes perfect sense to me - it’s effectively mirroring how PHP is actually distributed for a great number of environments already.
However, I find the concept of then adding in Composer/Pickle to be a very odd choice, and a poor one “politically”.
As someone else said, bundling composer sounds like an official endorsement of PHP-FIG, which I suspect a number of people would have issues with.
On a purely technical level - it makes little sense. As demonstrated above, a decent number of environments are not going to ship it as an included tool anyway.
Hi!
I think there is value in reducing the number of ‘bundled’ things,
particularly given that Debian (and thus Ubuntu), Centos and OS X all
distribute PEAR/PECL as a separate package. On the Linux distro's
it’s a separate (but possibly “recommended” by php-cli etc) package.
On OSX there is/usr/lib/install-pear-nozlib.phar.
Don't see how it matters what distros do. They certainly build with
non-default options and can re-combine stuff as they want. If you use a
distro it doesn't matter to you how PHP build behaves since you never
interact with it.
However, I find the concept of then adding in Composer/Pickle to be a
very odd choice, and a poor one “politically”.
What you mean here? Why is it odd, given the popularity of composer,
which is I think an established fact? Of course, not everybody uses it
everywhere - as each other tool, it is useful for soem specific scenarios.
And what you mean by "politically"?
As someone else said, bundling composer sounds like an official
endorsement of PHP-FIG, which I suspect a number of people would have
issues with.
No it doesn't. What it has to do with PHP-FIG at all? You can use
composer and create composer packages without ever hearing of PHP-FIG,
ever interacting with it or ever needing to. In fact, I don't think FIG
is ever mentioned on the composer site, except when referencing
documents like PSR-0.
I almost no idea what "issues" with PHP-FIG are, but whatever they are,
they are completely irrelevant to the question of whether composer is a
useful tool. IMO, it is, but if people think it is not, we could have a
vote and see.
On a purely technical level - it makes little sense. As demonstrated
above, a decent number of environments are not going to ship it as an
included tool anyway.
Well, yes, of course - I thought that the whole question is that we
should start providing it as an option when building PHP, of course we
would not cover environments which don't do it.
Stas Malyshev
smalyshev@gmail.com
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.
Even if Pear and Pecl overlap and share code, it would be better to
focus on the end-user capabilities and have separate RFCs for altering
those capabilities, rather than just trying to do everything in one
RFC. i.e. have:
One RFC to deprecate then remove the ability to install Pear userland
code modules.
A second RFC to deprecate Pecl and optionally start using Pickle.
Can you clarify one thing though - am I correct in that Pickle is
completely userland code? So why does it need to be 'shipped' with
PHP. Why can't it be a separate download?
cheers
Dan
pickle would still have the same problem (
https://github.com/FriendsOfPHP/pickle/issues/133)
Needs moar macros:
https://travis-ci.org/mkoppanen/imagick/builds/150948947
2016-09-05 11:51 GMT+02:00 Dan Ackroyd danack@basereality.com:
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.Even if Pear and Pecl overlap and share code, it would be better to
focus on the end-user capabilities and have separate RFCs for altering
those capabilities, rather than just trying to do everything in one
RFC. i.e. have:One RFC to deprecate then remove the ability to install Pear userland
code modules.A second RFC to deprecate Pecl and optionally start using Pickle.
Can you clarify one thing though - am I correct in that Pickle is
completely userland code? So why does it need to be 'shipped' with
PHP. Why can't it be a separate download?
I think the idea involved from other languages package managers like nodejs
where npm is shipped with nodejs in single package and all developers neet
to do
is update to latest version
https://docs.npmjs.com/getting-started/installing-node
"Node comes with npm installed so you should have a version of npm.
However, npm gets updated more frequently than Node does, so you'll want to
make sure it's the latest version."
cheers
Danpickle would still have the same problem (
https://github.com/FriendsOfPHP/pickle/issues/133)Needs moar macros:
https://travis-ci.org/mkoppanen/imagick/builds/150948947--
--
regards / pozdrawiam,
Michał Brzuchalski
brzuchalski.com
I think the idea involved from other languages package managers like nodejs
I think you have your history in a twist there: node.js was first
released in 2009, by which time PEAR was already ten years old, and
heading towards decline.
The more likely inspiration is CPAN, Perl's package archive, whose
command-line interface ships as a core module.
More relevantly, the point in such bundling is to give users an official
way of "bootstrapping" their environment, without having to go online
and figure out what to do next.
Regards,
--
Rowan Collins
[IMSoP]
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
I highly recommend reading the twitter poll and accompanying thread at
https://twitter.com/dshafik/status/756337267547832320
I don't think that question is phrased correctly. It is asking about
PEAR, and not PECL.
I don't think we should deprecate anything, until pickle is deemed
stable, and all issues with it are resolved (if there are any). So
instead of suggesting to deprecate something, perhaps it would be a
better idea to add pickle first - and only then even begin to figure
out whether it's better than "pecl" for installing PHP extensions.
"At the same time, we'd like to include composer/pickle as optional
(under build flags –with-composer and –with-pickle) for 7.2, then
enabled by default in 7.3. "
I don't think we should bundle composer, and also don't think it should
be an optional install. If it's an add-on (action required to enable
pickle), people won't do it, and nobody tests it - and continues to use
"pecl", which allthough not ideal, does do the job excellently.
I believe that pickle solves the issues with regards to pecl, and have run
the idea passed Jordi and Pierre. Both are fine with this RFC. :)
What are these issues with the "pecl" installation tool? The RFC has no
mention of this.
One of them could be that it gets very few maintenance, and it's a
little bit of a pain to update. Anything new should at least solve that.
That also means there need to be at least 3+ people that know it well
enough to be able to update, maintain and roll out releases.
I understand that adding in composer/pickle is just setting us up for
having a future "Deprecate composer/pickle & Replace with foo/bar" RFC, so
I've proposed the voting reflect that some people will just want to
deprecate/remove pear/pecl and not replace them at all.
You can't really ship PHP without a way to install extensions though!
And it should work also work out of the box, without any other tricks or
steps to make it working. That means, not having to run "composer
install" in order to get a working "pickle" tool. A phar might be an
idea.
All in all, I think it is premature to want to remove something, without
fully understanding the replacement tool. So, the first step would be to
add something, and not call for the removal of things.
cheers,
Derick
And it should work also work out of the box, without any other tricks or
steps to make it working. That means, not having to run "composer
install" in order to get a working "pickle" tool. A phar might be an
idea.
As I understand, PEAR already needs some bootstrapping on Windows,
provided as a one-shot batch file. But, yes, "bundling" in my mind would
mean providing a PHAR file rather than just a composer.json and a readme.
Regards,
--
Rowan Collins
[IMSoP]
Am 05.09.2016 um 12:13 schrieb Derick Rethans:
You can't really ship PHP without a way to install extensions though!
Why not?
IMHO, PHP should not be shipped with any tool for installing PHP
components (PEAR Installer, Composer, ...) or extensions (PECL Installer,
...).
In my experience, people either install PHP using the package manager of
their OS distribution or they build PHP from the sources themselves. In
the latter case, they know how to build/install extensions manually and do
not need a tool for that.
Hi,
Am 05.09.2016 um 12:13 schrieb Derick Rethans:
You can't really ship PHP without a way to install extensions though!
Why not?
IMHO, PHP should not be shipped with any tool for installing PHP
components (PEAR Installer, Composer, ...) or extensions (PECL Installer,
...).In my experience, people either install PHP using the package manager of
their OS distribution or they build PHP from the sources themselves. In
the latter case, they know how to build/install extensions manually and do
not need a tool for that.
Not in my case. In a few cases I needed to install extensions that were
not provided by my package manager.
Regards
Thomas
Am 05.09.2016 um 12:13 schrieb Derick Rethans:
You can't really ship PHP without a way to install extensions though!
Why not?
IMHO, PHP should not be shipped with any tool for installing PHP
components (PEAR Installer, Composer, ...) or extensions (PECL Installer,
...).In my experience, people either install PHP using the package manager
of their OS distribution,
One of PHPs biggest strengths is the availability of an extension for
nearly everything. There are 1000s out there. Some made by single
people, some by small groups of people, or some by large companies. You
can't expect all of these extensions to be available through
distribution's packages.
or they build PHP from the sources
themselves. In the latter case, they know how to build/install
extensions manually and do not need a tool for that.
They'd still need to run the equivalent to "pecl" to install these
manually build extensions. Or at least the "pecl download" variant.
cheers,
Derick
--
https://derickrethans.nl | https://xdebug.org | https://dram.io
Like Xdebug? Consider a donation: https://xdebug.org/donate.php
twitter: @derickr and @xdebug
One of PHPs biggest strengths is the availability of an extension for
nearly everything. There are 1000s out there. Some made by single
people, some by small groups of people, or some by large companies. You
can't expect all of these extensions to be available through
distribution's packages.
By the same reasoning, most of them won't be available on pecl.php.net
either. I'm curious, do people often run their own PECL-compatible
"channel" servers?
They'd still need to run the equivalent to "pecl" to install these
manually build extensions. Or at least the "pecl download" variant.
Not really, the ones I've used come as a tarball, use "phpize" and
standard build tools, and have a "make install" to put the .so file in
the right place. Then you just have to add "extension=foo.so" in the
appropriate ini location (which you have to do after pecl install anyway).
I agree that a stable tool for installing from pecl.php.net should
always be included, though.
Regards,
Rowan Collins
[IMSoP]
On Tue, Sep 6, 2016 at 12:40 PM, Rowan Collins rowan.collins@gmail.com
wrote:
One of PHPs biggest strengths is the availability of an extension for
nearly everything. There are 1000s out there. Some made by single
people, some by small groups of people, or some by large companies. You
can't expect all of these extensions to be available through
distribution's packages.By the same reasoning, most of them won't be available on pecl.php.net
either. I'm curious, do people often run their own PECL-compatible
"channel" servers?
in the past it was a pita so nobody really done it, but then Fabien
contributed Pirum (http://pirum.sensiolabs.org/) after that for a while it
was "hip" to run your own pear channel(from server/channel side pear and
pecl is the same).
nowdays most active projects switched from custom pear channels to
composer/packagist
They'd still need to run the equivalent to "pecl" to install these
manually build extensions. Or at least the "pecl download" variant.
Not really, the ones I've used come as a tarball, use "phpize" and
standard build tools, and have a "make install" to put the .so file in the
right place. Then you just have to add "extension=foo.so" in the
appropriate ini location (which you have to do after pecl install anyway).I agree that a stable tool for installing from pecl.php.net should always
be included, though.
agree, and on windows we could dramatically improve the situation, afair
Anatol recently added the capability for peclweb to link/list the windows
binaries for the pecl releases, and pickle uses the dll-s from
windows.php.net to be able to install the pecl extensions without requiring
the build toolchain to be present:
https://github.com/FriendsOfPHP/pickle/blob/71fd8a97ac6c3f67fbb7f032533ddaa31cb6b662/src/Package/Util/Windows/DependencyLib.php
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
On Tue, Sep 6, 2016 at 12:40 PM, Rowan Collins rowan.collins@gmail.com
wrote:One of PHPs biggest strengths is the availability of an extension for
nearly everything. There are 1000s out there. Some made by single
people, some by small groups of people, or some by large companies. You
can't expect all of these extensions to be available through
distribution's packages.By the same reasoning, most of them won't be available on pecl.php.net
either. I'm curious, do people often run their own PECL-compatible
"channel" servers?in the past it was a pita so nobody really done it, but then Fabien
contributed Pirum (http://pirum.sensiolabs.org/) after that for a while it
was "hip" to run your own pear channel(from server/channel side pear and
pecl is the same).
nowdays most active projects switched from custom pear channels to
composer/packagistThey'd still need to run the equivalent to "pecl" to install these
manually build extensions. Or at least the "pecl download" variant.
Not really, the ones I've used come as a tarball, use "phpize" and
standard build tools, and have a "make install" to put the .so file in
the
right place. Then you just have to add "extension=foo.so" in the
appropriate ini location (which you have to do after pecl install
anyway).I agree that a stable tool for installing from pecl.php.net should
always
be included, though.agree, and on windows we could dramatically improve the situation, afair
Anatol recently added the capability for peclweb to link/list the windows
binaries for the pecl releases, and pickle uses the dll-s from
windows.php.net to be able to install the pecl extensions without
requiring
the build toolchain to be present:
pickle install zip f.e. will look at pecl.php.net too btw
Please be cautious - composer isn't a complete replacement for PEAR because
it doesn't behave the same way. For the most part this is a good thing, but
please consider the following.
On not one but two occasions I was tasked after being hired with upgrading
PHP versions from 4.x to 5.3. In both cases the programmers on staff who
had inherited the balls of mud in question swore up and down it couldn't be
done - on both occasions it was because they weren't copying the PEAR
libraries over to the new PHP install.
PEAR is a global installer, and unfortunately I imagine there are a lot of
legacy sites that have been inherited by inexperienced coders who don''t
know what it is (cause it is used so rarely these days) that have pear libs
in use. If they need to build a new version of PHP they are at a complete
loss unless they know what they are doing because, more often than not, the
requirement of pear libraries in PHP apps that use them go undocumented.
Composer is superior for several reasons, but one of them is that it
doesn't share this flaw. The requirements of a composer project are listed
explicitly in the composer.json file - often down to the version # of the
code in question.
While abandoning PEAR seems sensible, abandoning its plugins, not so much.
To say nothing of PECL extensions which are, if I recall correctly, written
in C++ and extend the PHP runtime directly.
Also, as Tony Marston pointed out, there are CPanel systems that allow the
pear libraries to be managed from a web gui. Given time I'm sure the folks
at cpanel will build new interfaces for new systems if it's possible.
Composer however doesn't really allow for this since the dependencies
belong to the PHP application, not the server. Does it make sense for any
new system to allow for server wide installing? Composer does have global
requiring, but it's usually for support tools meant for use at the command
line like PHP Unit.
Despite the misgivings above, I do support the aims of this RFC and hope
they are considered going forward.
Hi internals,
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
I highly recommend reading the twitter poll and accompanying thread at
https://twitter.com/dshafik/status/756337267547832320I believe that pickle solves the issues with regards to pecl, and have run
the idea passed Jordi and Pierre. Both are fine with this RFC. :)I understand that adding in composer/pickle is just setting us up for
having a future "Deprecate composer/pickle & Replace with foo/bar" RFC, so
I've proposed the voting reflect that some people will just want to
deprecate/remove pear/pecl and not replace them at all.I'm also proposing voting choices around the optional/default introduction
of composer/pickle.
- Davey
- szept. 5. 17:32 ezt írta ("Michael Morris" tendoaki@gmail.com):
Please be cautious - composer isn't a complete replacement for PEAR
because
it doesn't behave the same way. For the most part this is a good thing,
but
please consider the following.On not one but two occasions I was tasked after being hired with upgrading
PHP versions from 4.x to 5.3. In both cases the programmers on staff who
had inherited the balls of mud in question swore up and down it couldn't
be
done - on both occasions it was because they weren't copying the PEAR
libraries over to the new PHP install.PEAR is a global installer, and unfortunately I imagine there are a lot of
legacy sites that have been inherited by inexperienced coders who don''t
know what it is (cause it is used so rarely these days) that have pear
libs
in use. If they need to build a new version of PHP they are at a complete
loss unless they know what they are doing because, more often than not,
the
requirement of pear libraries in PHP apps that use them go undocumented.Composer is superior for several reasons, but one of them is that it
doesn't share this flaw. The requirements of a composer project are listed
explicitly in the composer.json file - often down to the version # of the
code in question.While abandoning PEAR seems sensible, abandoning its plugins, not so much.
To say nothing of PECL extensions which are, if I recall correctly,
written
in C++ and extend the PHP runtime directly.Also, as Tony Marston pointed out, there are CPanel systems that allow the
pear libraries to be managed from a web gui. Given time I'm sure the
folks
at cpanel will build new interfaces for new systems if it's possible.
Composer however doesn't really allow for this since the dependencies
belong to the PHP application, not the server. Does it make sense for any
new system to allow for server wide installing? Composer does have global
requiring, but it's usually for support tools meant for use at the command
line like PHP Unit.Despite the misgivings above, I do support the aims of this RFC and hope
they are considered going forward.Hi internals,
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
I highly recommend reading the twitter poll and accompanying thread at
https://twitter.com/dshafik/status/756337267547832320I believe that pickle solves the issues with regards to pecl, and have
run
the idea passed Jordi and Pierre. Both are fine with this RFC. :)I understand that adding in composer/pickle is just setting us up for
having a future "Deprecate composer/pickle & Replace with foo/bar" RFC,
so
I've proposed the voting reflect that some people will just want to
deprecate/remove pear/pecl and not replace them at all.I'm also proposing voting choices around the optional/default
introduction
of composer/pickle.
- Davey
For the record pear support local install and composer also provides global
installmethods but you are right that they use the opposite by default.
Also, as Tony Marston pointed out, there are CPanel systems that allow the
pear libraries to be managed from a web gui. Given time I'm sure the folks
at cpanel will build new interfaces for new systems if it's possible.
Composer however doesn't really allow for this since the dependencies
belong to the PHP application, not the server.
This is the part of the tree that I'm also climbing where we are helping
port legacy hosting over to to a newer framework. Silly little things
like mysql being dropped while there is nobody to re-write all the code
to mysqli. Restoring extensions from pecl still needs pecl to exist even
for pickle to access them including the web interface to catalogue them?
And I view PEAR in the same light. So this is not about 'Deprecate' the
code, but just the loader bit?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Also, as Tony Marston pointed out, there are CPanel systems that allow the
pear libraries to be managed from a web gui.
So this is not about 'Deprecate' the
code, but just the loader bit?
Have a look at my post from 03/09/2016 15:45, or the extra text from it
that Davey has edited into the RFC. The only thing being suggested for
removal is the command-line tool which is currently bundled with the
default build. Everything else will still be there, as long as the
shrinking number of volunteers keeps it running.
Regards,
--
Rowan Collins
[IMSoP]
Also, as Tony Marston pointed out, there are CPanel systems that allow
the
pear libraries to be managed from a web gui. Given time I'm sure the
folks
at cpanel will build new interfaces for new systems if it's possible.
Composer however doesn't really allow for this since the dependencies
belong to the PHP application, not the server.This is the part of the tree that I'm also climbing where we are helping
port legacy hosting over to to a newer framework. Silly little things
like mysql being dropped while there is nobody to re-write all the code
to mysqli.
https://github.com/dshafik/php7-mysql-shim — I already solved that problem,
at least in the short term.
Restoring extensions from pecl still needs pecl to exist even
for pickle to access them including the web interface to catalogue them?
And I view PEAR in the same light. So this is not about 'Deprecate' the
code, but just the loader bit?
Nobody is saying to do anything except unbundle the command line tools.
Also, pickle can install pecl extensions from places like publicly
accessible git and svn repos (like github, git.php.net or svn.php.net).
https://github.com/dshafik/php7-mysql-shim — I already solved that problem,
at least in the short term.
Another one for PHPSurgery MUST get that updated ... when time permits.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Nobody is saying to do anything except unbundle the command line tools.
And I would say that we should see whether the new tools work
perfectly fine first before even considering that.
cheers,
Derick
Please be cautious - composer isn't a complete replacement for PEAR
because it doesn't behave the same way. For the most part this is a good
thing, but please consider the following.On not one but two occasions I was tasked after being hired with upgrading
PHP versions from 4.x to 5.3. In both cases the programmers on staff who
had inherited the balls of mud in question swore up and down it couldn't be
done - on both occasions it was because they weren't copying the PEAR
libraries over to the new PHP install.PEAR is a global installer, and unfortunately I imagine there are a lot of
legacy sites that have been inherited by inexperienced coders who don''t
know what it is (cause it is used so rarely these days) that have pear libs
in use. If they need to build a new version of PHP they are at a complete
loss unless they know what they are doing because, more often than not, the
requirement of pear libraries in PHP apps that use them go undocumented.
Even ten years ago, best practices was not to install PEAR packages
globally due to different projects on shared hosts needing different
versions. Instead we installed them locally, committed them to RCS, and
used the include_path to control include locations.
Composer is superior for several reasons, but one of them is that it
doesn't share this flaw. The requirements of a composer project are listed
explicitly in the composer.json file - often down to the version # of the
code in question.While abandoning PEAR seems sensible, abandoning its plugins, not so much.
Nobody is suggesting this. Though it might be good to push them off from
under php.net, that doesn't stop them existing, and that's not part of this
RFC.
To say nothing of PECL extensions which are, if I recall correctly,
written in C++ and extend the PHP runtime directly.
Written in C, and yes, that's the difference between PEAR and PECL, the
former are userland, the latter are written in C. This is where pickle
comes in.
Also, as Tony Marston pointed out, there are CPanel systems that allow the
pear libraries to be managed from a web gui. Given time I'm sure the folks
at cpanel will build new interfaces for new systems if it's possible.
Composer however doesn't really allow for this since the dependencies
belong to the PHP application, not the server. Does it make sense for any
new system to allow for server wide installing? Composer does have global
requiring, but it's usually for support tools meant for use at the command
line like PHP Unit.
Actually, I think Tony is pointing to pear-web, a PEAR provided web
interface for PEAR itself (which can be used instead of the CLI tool).
Which isn't going away, it will just be unbundled. In 8.0.
Nothing we're doing changes anything for CPanel and the like except they
may now need to replicate the install part of PEAR themselves from the PHP
compilation. It's very simple.
Despite the misgivings above, I do support the aims of this RFC and hope
they are considered going forward.
Thank you.
- Davey
Hi internals,
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.
Can pickle package the extension? That's basically the only thing that I
use pecl for:
$ pecl package
(it creates tgz based on the info in package.xml)
I guess it's something other ext devs that have got exts on PECL would like
to have too...
Cheers
Jakub
Hi internals,
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
I highly recommend reading the twitter poll and accompanying thread at
https://twitter.com/dshafik/status/756337267547832320I believe that pickle solves the issues with regards to pecl, and have run
the idea passed Jordi and Pierre. Both are fine with this RFC. :)I understand that adding in composer/pickle is just setting us up for
having a future "Deprecate composer/pickle & Replace with foo/bar" RFC, so
I've proposed the voting reflect that some people will just want to
deprecate/remove pear/pecl and not replace them at all.I'm also proposing voting choices around the optional/default introduction
of composer/pickle.
- Davey
Yes please! +1
This would be another major step forward for the PHP ecosystem.
--
Connect with me on http://twitter.com/jwage <http://twitter.com/jwage
Regards,
Mike
Hi internals,
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
I highly recommend reading the twitter poll and accompanying thread at
https://twitter.com/dshafik/status/756337267547832320I believe that pickle solves the issues with regards to pecl, and have run
the idea passed Jordi and Pierre. Both are fine with this RFC. :)I understand that adding in composer/pickle is just setting us up for
having a future "Deprecate composer/pickle & Replace with foo/bar" RFC, so
I've proposed the voting reflect that some people will just want to
deprecate/remove pear/pecl and not replace them at all.I'm also proposing voting choices around the optional/default introduction
of composer/pickle.
+1 on stabbing the PEAR installer from the source distribution.
-1 on adding anything else. Composer is as easy to install separately as PEAR from their origin as well as from OS distributions these days.
On a side note, we should look into evolving ext/phar to a plugin based system, not the hard coded foreign feature sink it currently is (with regards to compression and signing support at first, with the underlying file format being next).
Cheers,
Mike
+1 on stabbing the PEAR installer from the source distribution.
The PEAR installer is not just the PEAR installer, it
installs and packages PECL extensions too. Actually, it's the only way
how people directly install PECL extensions.
-1 on adding anything else. Composer is as easy to install separately
as PEAR from their origin as well as from OS distributions these days.
So do you want PHP not to have a tool that installs extensions out of
the box? Frankly, I think that's irresponsible.
cheers,
Derick
Hi Davey,
thanks for the proposal and excuse my rather longish reply already.
[...]
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.
[...]
Before discussing the proposal, I wanna go back one step and disaggregate the main use cases of what pear does so far (I simplified that a bit, but look at pear help on your own):
- Install PHP extensions written in C/C++ through pecl and pecl.php.net
- Install PHP libraries written in PHP through pear.php.net
- Act as a version manager for both C and PHP based extensions/libraries
- Package pecl packages for release
Probably less used (my guess!):
- Building an RPM spec file from a PEAR package
- Adding additional PEAR channels to install more dependencies than what is on pecl.php.net and pear.php.net
- Signing packages
- I’ve heard there might be a web interface somewhere but I have no idea about it :)
I believe out of those use cases there should only be two that are supported in core:
- Install PHP extensions written in C/C++ based on a global repository like pecl.php.net (or it’s successor)
- Tooling for maintaining such PHP extensions written in C/C++
Note: The second one could be solved in userland but I think for convenience reasons this should be supported by core.
For a healthy ecosystem we want to have alignment but also competition on central pieces of infrastructure like composer is. Don’t get me wrong, composer was programmer-heaven-sent and I love using it but if somebody has a better idea I don’t want core to provide relative competitive advantage just because it’s bundled. Maybe if PHP would not have shipped pear it would be long gone. Also I would argue that the lifecycle of a package management tool is different than the lifecycle of language, meaning that a package management needs more upgrades than the language so bundling doesn't really fit.
Having said that, I think we should offer an easy way to install composer in the core as a practical, convenient and realistic compromise. Something like php --composer-install that basically does curl getcomposer.org/composer.phar > /usr/local/bin/composer && chmod +x /usr/local/bin/composer. If we want to get fancy even a script that replaces itself with the content of getcomposer.org/composer.phar. This could also include a policy that we would include competing package managers if they proof a certain level of traction in the same way.
Now for pickle specifically: as I have never used it personally I have no way to judge it’s stability or defect rate. I would love to hear an opinion on that from people with more experience here. Also what about traction: looking at the commit history of the project, could some of the authors chime and provide some perspective on wether it's more or less done, what the development roadmap (if any) looks like and what would be caveats of including it.
cu,
Lars
I'm also proposing voting choices around the optional/default introduction
of composer/pickle.
I've just been through an exercise to give PHP_CodeSniffer a go on my
code base. I've not worried too much about that in the past since
Eclipse in general flags style problems as well as simple errors. This
is a package that SUSE does not support, so the current install path is
just PEAR. I don't see packages like this as a library that my sites
use. It is a stand alone tool ( and a command line one at that :) ) so
how would loading that be managed if PEAR is not available?
I had the problem having loaded the tool in finding the rule sets so
that I could create one suitable for my own application. That is
dictated by SUSE was was not quite where I expected it, so this may also
be something that an alternative tool loader might be able to help with?
Main reason for loading was to give some of the PSR rule checks a try to
see just what affect they would have on the code, but I don't think this
approach will help with the structural changes needed?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
I've just been through an exercise to give PHP_CodeSniffer a go on my
code base. I've not worried too much about that in the past since
Eclipse in general flags style problems as well as simple errors. This
is a package that SUSE does not support, so the current install path is
just PEAR. I don't see packages like this as a library that my sites
use. It is a stand alone tool ( and a command line one at that :) ) so
how would loading that be managed if PEAR is not available?
PHP_CodeSniffer is already compatible with Composer, and Composer has
the ability to specify dependencies, and dependencies intended for
development. After running composer install you can execute
vendor/bin/phpcs, and if you were working collaboratively,
collaborators would all have the same toolset that you have.
--
Daniel Morris
daniel@honestempire.com
I've just been through an exercise to give PHP_CodeSniffer a go on my
code base. I've not worried too much about that in the past since
Eclipse in general flags style problems as well as simple errors. This
is a package that SUSE does not support, so the current install path is
just PEAR. I don't see packages like this as a library that my sites
use. It is a stand alone tool ( and a command line one at that :) ) so
how would loading that be managed if PEAR is not available?PHP_CodeSniffer is already compatible with Composer, and Composer has
the ability to specify dependencies, and dependencies intended for
development. After running composer install you can execute
vendor/bin/phpcs, and if you were working collaboratively,
collaborators would all have the same toolset that you have.
I know this is a problem for PHP_CodeSniffer to rework it's
documentation, but it is a chicken and egg. PEAR provides a framework to
store things like PHP_CodeSniffer in the common area away from our web
folders. A similar set of guidelines to install via composer are needed
as an alternative and those are not currently in place? The point I
think here is that removing the built in installer for one off users is
what is being discussed and that should only happen if there is an
alternative. While composer can be used as an alternative, is it really
the best alternative for a simple built in loader?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
I've just been through an exercise to give PHP_CodeSniffer a go on my
code base. I've not worried too much about that in the past since
Eclipse in general flags style problems as well as simple errors. This
is a package that SUSE does not support, so the current install path is
just PEAR. I don't see packages like this as a library that my sites
use. It is a stand alone tool ( and a command line one at that :) ) so
how would loading that be managed if PEAR is not available?PHP_CodeSniffer is already compatible with Composer, and Composer has
the ability to specify dependencies, and dependencies intended for
development. After running composer install you can execute
vendor/bin/phpcs, and if you were working collaboratively,
collaborators would all have the same toolset that you have.I know this is a problem for PHP_CodeSniffer to rework it's
documentation,
The docs seem to be fine:
https://github.com/squizlabs/PHP_CodeSniffer#installation.
but it is a chicken and egg. PEAR provides a framework to
store things like PHP_CodeSniffer in the common area away from our web
folders. A similar set of guidelines to install via composer are needed
as an alternative and those are not currently in place?
The global command appears to solve that:
https://getcomposer.org/doc/03-cli.md#global.
--
Christoph M. Becker
I've just been through an exercise to give PHP_CodeSniffer a go on my
code base. I've not worried too much about that in the past since
Eclipse in general flags style problems as well as simple errors. This
is a package that SUSE does not support, so the current install path is
just PEAR. I don't see packages like this as a library that my sites
use. It is a stand alone tool ( and a command line one at that :) ) so
how would loading that be managed if PEAR is not available?PHP_CodeSniffer is already compatible with Composer, and Composer has
the ability to specify dependencies, and dependencies intended for
development. After running composer install you can execute
vendor/bin/phpcs, and if you were working collaboratively,
collaborators would all have the same toolset that you have.I know this is a problem for PHP_CodeSniffer to rework it's
documentation,The docs seem to be fine:
https://github.com/squizlabs/PHP_CodeSniffer#installation.but it is a chicken and egg. PEAR provides a framework to
store things like PHP_CodeSniffer in the common area away from our web
folders. A similar set of guidelines to install via composer are needed
as an alternative and those are not currently in place?The
globalcommand appears to solve that:
https://getcomposer.org/doc/03-cli.md#global.
That is the chicken ... if you ARE already composer user then it will
make some sense, but pear gives a phpcs -h which works out of the box.
./vendor/bin/phpcs -h does not sound right as an alternative? And I
would expect different installations of composer will affect that
installation?
I have no doubt that composer can be made to work. The question here is
if that is as easy to achieve as simply keeping PEAR installer as the
fall back process? Certainly when I last tried to set up composer I ran
into difficulty because I have 4 versions of PHP active. Something which
pear seems to cope with without a problem.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
2016-09-08 14:13 GMT+02:00 Lester Caine lester@lsces.co.uk:
I've just been through an exercise to give PHP_CodeSniffer a go on my
code base. I've not worried too much about that in the past since
Eclipse in general flags style problems as well as simple errors. This
is a package that SUSE does not support, so the current install path
is
just PEAR. I don't see packages like this as a library that my sites
use. It is a stand alone tool ( and a command line one at that :) ) so
how would loading that be managed if PEAR is not available?PHP_CodeSniffer is already compatible with Composer, and Composer has
the ability to specify dependencies, and dependencies intended for
development. After running composer install you can execute
vendor/bin/phpcs, and if you were working collaboratively,
collaborators would all have the same toolset that you have.I know this is a problem for PHP_CodeSniffer to rework it's
documentation,The docs seem to be fine:
https://github.com/squizlabs/PHP_CodeSniffer#installation.but it is a chicken and egg. PEAR provides a framework to
store things like PHP_CodeSniffer in the common area away from our web
folders. A similar set of guidelines to install via composer are needed
as an alternative and those are not currently in place?The
globalcommand appears to solve that:
https://getcomposer.org/doc/03-cli.md#global.That is the chicken ... if you ARE already composer user then it will
make some sense, but pear gives a phpcs -h which works out of the box.
./vendor/bin/phpcs -h does not sound right as an alternative?
Why does it seem not right? It's perfectly right and the way to go if
you're using Composer.
An alternative would be to use Composer's global require and adding the
global "bin" directory
of Composer to your PATH variable.
And I
would expect different installations of composer will affect that
installation?
What do you mean by "affect that installation"?
Regards, Niklas
I have no doubt that composer can be made to work. The question here is
if that is as easy to achieve as simply keeping PEAR installer as the
fall back process? Certainly when I last tried to set up composer I ran
into difficulty because I have 4 versions of PHP active. Something which
pear seems to cope with without a problem.--
Lester Caine - G8HFLContact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
That is the chicken ... if you ARE already composer user then it will make some sense, but pear gives a phpcs -h which works out of the box. ./vendor/bin/phpcs -h does not sound right as an alternative?Why does it seem not right? It's perfectly right and the way to go if
you're using Composer.An alternative would be to use Composer's global require and adding the
global "bin" directory of Composer to your PATH variable.
bash: ./vendor/bin/phpcs: No such file or directory
Which I presume means I do need to set up some path, but currently I no
idea where 'composer global require "squizlabs/php_codesniffer=*"' has
put it?
And I would expect different installations of composer will affect that installation?What do you mean by "affect that installation"?
Currently having followed the installation guide I have things working
on a home directory. This is probably what people expect today, but I
still expect tools to be available which ever login I use ... testing
different client profiles.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
bash: ./vendor/bin/phpcs: No such file or directory
Which I presume means I do need to set up some path, but currently I no
idea where 'composer global require "squizlabs/php_codesniffer=*"' has
put it?
That's the directory where it goes if you don't use "--global": the
vendor directory of the current project.
The "--global" documentation refers to COMPOSER_HOME as the location it
uses, which is documented here:
https://getcomposer.org/doc/03-cli.md#composer-home It boils down to (I
think) "~/.composer/vendor/bin/phpcs"
Currently having followed the installation guide I have things working
on a home directory. This is probably what people expect today, but I
still expect tools to be available which ever login I use ... testing
different client profiles.
You could also just create a composer.json file in /usr/share somewhere
and run "composer install" there. You could then make a symlink from
/usr/bin/phpcs to wherever the executable is, and it would be in every
user's default path as well.
Hi Lester,
Currently having followed the installation guide I have things working
on a home directory. This is probably what people expect today, but I
still expect tools to be available which ever login I use ... testing
different client profiles.
There are a few options, as I'm sure you're aware, haha. By default,
global requirements are going into the executor's home directory.
However, you can configure all of those paths at run time. My advice
(if you cannot (or simply prefer not to) install these types of tools
per-application) would be to configure those paths to point to some
global space in (what I presume is a) shared development space where
it makes sense to have these tools installed globally (phpcs, phpunit,
etc). Then you would have the task of making sure that global bin-path
is in each users environment when they log in.
However! (and I don't know if this is "best practice" or whatever) ...
you could decide to specify bin-dir to be some UNIX / Windows path
that is in environments by default. The risk here is that you collide
with pre-existing binaries / symlinks (which is a trade-off to global
installations in general). Let's see what we can do...
# For purposes of demonstration, I'm doing this as a user that can create
# directories in /opt and can create and execute files in /usr/local/sbin
# I wouldn't do this as root, I'm just lazy...
$ sudo su -
$ whoami
root
# Arbitrarily decide to install here globally
$ mkdir /opt/composer
# Tell composer where to install dependencies
$ composer global config vendor-dir /opt/composer/vendor
# Tell composer where to put "binaries" (symlinks)
$ composer global config bin-dir /usr/local/sbin
# Verify our settings "took"
$ composer global config --list
<snip>
[vendor-dir] /opt/composer/vendor
[bin-dir] /usr/local/sbin
# Note that there are other paths that should probably be specified
(where caches are stored, etc)
# In this example, Composer's global config is in-fact in root's home
directory. Caches are in root's
# home directory. This may or may not be acceptable, but is definitely
configurable to whatever you want
# Install PHPCS globally and cross fingers >_<
$ composer global require squizlabs/php_codesniffer
# Drop elevated permissions
$ exit
$ whoami
vagrant
# Try to use PHPCS out of my home directory with no special pathiness...
$ which phpcs
/usr/local/sbin/phpcs
$ phpcs --version
PHP_CodeSniffer version 2.7.0 (stable) by Squiz (http://www.squiz.net)
In this way, you can install composer "binaries" to a global
location that is accessible by default by normal users on your system.
This was done on a CentOS 7 machine, but I am positive this can be
equivalently applied to Windows or any environment, really.
I'll admit that most folks (it seems, anecdotally) have gone the way
of installing these development tools per-application using
require-dev but I completely understand where you're coming from. I
just wanted to show you what's possible.
I hope this helps, Lester.
-Dustin
--
Dustin Wheeler | Software Developer
NC State University
m: mdwheele@ncsu.edu | w: 5-9786
"If you don't know where you're going, it's easy to iteratively not get there."
In this way, you can install composer "binaries" to a global
location that is accessible by default by normal users on your system.
This was done on a CentOS 7 machine, but I am positive this can be
equivalently applied to Windows or any environment, really.
Another couple of hours wasted, but I understand where things are now,
and basically the simple fact is that composer global mode is nothing of
the sort. The PHP_CodeSniffer composer install does not work and I
understand NOW why the Smarty one also failed. I was expecting the files
to be available to the nginx server but they were hidden away in my home
directory. I still have to work out just how to reset things to move the
code to /usr/shared/phpx/composer to parallel the PEAR version.
The main feedback here has been that nothing should be removed until
there is a working alternative, and I think there DOES need to be a
discussion on making a default installation of composer that provides a
global installation for tools like PHP_CodeSniffer and other global
tools before the current option is slated for deprecated.
My target client machines are windows rather than linux and each IT
technician has their own login and these change year on year, so the
tool chains all need to be globally installed, something PEAR is
designed to provide? An installation of composer needs to emulate that
model at the 'PHP' level otherwise we are looking at a major BC break?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
In this way, you can install composer "binaries" to a global
location that is accessible by default by normal users on your system.
This was done on a CentOS 7 machine, but I am positive this can be
equivalently applied to Windows or any environment, really.
Another couple of hours wasted, but I understand where things are now,
and basically the simple fact is that composer global mode is nothing of
the sort. The PHP_CodeSniffer composer install does not work and I
understand NOW why the Smarty one also failed. I was expecting the files
to be available to the nginx server but they were hidden away in my home
directory. I still have to work out just how to reset things to move the
code to /usr/shared/phpx/composer to parallel the PEAR version.The main feedback here has been that nothing should be removed until
there is a working alternative, and I think there DOES need to be a
discussion on making a default installation of composer that provides a
global installation for tools like PHP_CodeSniffer and other global
tools before the current option is slated for deprecated.My target client machines are windows rather than linux and each IT
technician has their own login and these change year on year, so the
tool chains all need to be globally installed, something PEAR is
designed to provide? An installation of composer needs to emulate that
model at the 'PHP' level otherwise we are looking at a major BC break?
In any practical sense, the PHP community at large has abandoned
system-level installation of tools over the course of the past decade.
That was one of the downfalls of PEAR: System-level installation of a
package whose stability wasn't measured in RHEL LTS releases are
basically a non-starter.
Just about every PHP tool I can think of these days, save PEAR/PECL, is
designed to be installed per-user ("global") or per-project (most
composer). That's how they want to be used. Trying to fight that
trend is setting yourself and your users up for a world of pain.
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.
(The Python community has also made steps in that direction with
virtualenv, which lets you avoid system-global code, too. Time will
tell how far that process goes there.)
--Larry Garfield
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.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
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
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.
You seem to be hell bent on removing the PECL installer, without having
a proven alternative in place first. Please prove whether
composer/pickle works (by adding it for a few releases), before we
decide (or rather, discuss) about removing the PECL installer.
cheers,
Derick
Another couple of hours wasted, but I understand where things are now,
and basically the simple fact is that composer global mode is nothing of
the sort. The PHP_CodeSniffer composer install does not work and I
understand NOW why the Smarty one also failed. I was expecting the files
to be available to the nginx server but they were hidden away in my home
directory. I still have to work out just how to reset things to move the
code to /usr/shared/phpx/composer to parallel the PEAR version.
PHP_CodeSniffer should not be run by the web server, it's a command-line
development tool, it should be run by the developer, or as part of a
build (e.g. Travis, Ant, etcetera)
Composer allows you to separate the dependencies, for example, in your
case; Smarty is a production and development dependency, and PHPCS is a
development dependency only, your composer.json should have something
similar to the following:
{
"require": {
"smarty/smarty": "~3.1"
},
"require-dev": {
"squizlabs/php_codesniffer": "^2.7"
}
}
That way, anytime someone runs composer install from your project
directory (or wherever the composer.json dependency is contained), it
will create a vendor directory with your dependencies, if you haven't
used the --no-dev flag when running composer install, you will have
PHPCS ready and waiting in vendor/bin, others will have the same
toolset you're using, so discrepancies between environments will have
been reduced.
--
Daniel Morris
daniel@honestempire.com
That is the chicken ... if you ARE already composer user then it will
make some sense, but pear gives a phpcs -h which works out of the box.
./vendor/bin/phpcs -h does not sound right as an alternative? And I
would expect different installations of composer will affect that
installation?
If I run composer global require "squizlabs/php_codesniffer=*", I get:
Changed current directory to /Users/dmorris/.composer
./composer.json has been created
Loading composer repositories with package information
Updating dependencies (including require-dev)
- Installing squizlabs/php_codesniffer (2.7.0)
Downloading: 100%
Writing lock file
Generating autoload files
Composer has indicated in its output where the executables have been
downloaded to, I could just add ~/.composer/vendor/bin to my $PATH
and then it essentially works the same way as PEAR. I generally prefer
to have project specific dependencies though, as do most others, I
believe.
This thread has turned into a Composer help/support thread now, which
I'm sure is not the original intention. I'd like to see the deprecation
of PEAR, it served many well for a long time, but Composer has made life
much easier for the majority.
--
Daniel Morris
daniel@honestempire.com
I know this is a problem for PHP_CodeSniffer to rework it's
documentation, but it is a chicken and egg. PEAR provides a framework to
store things like PHP_CodeSniffer in the common area away from our web
folders. A similar set of guidelines to install via composer are needed
as an alternative and those are not currently in place? The point I
think here is that removing the built in installer for one off users is
what is being discussed and that should only happen if there is an
alternative. While composer can be used as an alternative, is it really
the best alternative for a simple built in loader?
Most people develop and host in different environments, when installing
a package via composer for development purposes, you simply add it to
the require-dev section of composer.json and run: "composer install",
when it's time to deploy to the production environment, do "composer
install --no-dev" and it will not install development dependencies, so
PHP_CodeSniffer will not exist in any of your web folders. It wouldn't
even matter for most if they didn't skip the development dependencies in
production, since the vendor directory should live outside of the web
root.
Most packages that are actively maintained would have moved to
Composer/Packagist by now, those that are still requiring installation
via PEAR are probably not updated as frequently, and likely are still
using styles and patterns from the PHP 4 era.
--
Daniel Morris
daniel@honestempire.com