# Splitting the subject: the PECL/PHP relationship - Thread: https://externals.io/message/35112 - Original archive: https://news-web.php.net/php.internals/35112 - Started by Steph Fox on 2008-02-02T20:14:12+00:00 - Messages: 46 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/35112.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #35112 — Steph Fox — 2008-02-02T20:14:12+00:00 URL: https://externals.io/message/35112#35112 Hi all, Just so's Marcus and I don't have to keep cross-posting here... The problems of PECL vs core extensions are many, and exist with or without the PDO/CLA debate. Marcus (among others) says he wants to get as many extensions as possible out of the core and into PECL. I agree fully with this as a long-term aim, but feel strongly that the PECL infrastructure is not equipped to support it well at present. 1) Distribution woes need to end. With the work Greg's been doing lately on PHP_Archive/Phar, that's very close to being attainable now in the physical 'getting PECL'd extensions out to people' sense, but unless people are running CLI or CGI or have access to their own php.ini they still can't do much with those extensions. So we have to seriously consider how to recommend extensions to hosts, other than by shipping them with the PHP core. 2) Maintenance status needs to be part of the equation. 3) Stability needs to be part of the equation. 4) Appropriateness to a given PHP branch needs to be part of the equation. 5) CS and documentation need to be part of the equation. Thoughts? - Steph --- ## #35114 — Pierre Joye — 2008-02-02T20:38:04+00:00 URL: https://externals.io/message/35112#35114 · In reply to: #35112 > Thoughts? It is also possible to have both. It is even a good thing for what linux distributions told me about zip. About moving all extensions to PECL, we already discussed this problem and the conclusion was to continue like now. There was good reasons listed. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #35118 — Marcus Boerger — 2008-02-02T23:21:04+00:00 URL: https://externals.io/message/35112#35118 · In reply to: #35112 Hello Steph, what I want is php-src as minimum you can depend on. And php-default as release managers playground. The RM can then say what he thinks is mature enough to make it into a release. marcus Saturday, February 2, 2008, 9:14:12 PM, you wrote: > Hi all, > Just so's Marcus and I don't have to keep cross-posting here... The problems > of PECL vs core extensions are many, and exist with or without the PDO/CLA > debate. > Marcus (among others) says he wants to get as many extensions as possible > out of the core and into PECL. I agree fully with this as a long-term aim, > but feel strongly that the PECL infrastructure is not equipped to support it > well at present. > 1) Distribution woes need to end. With the work Greg's been doing lately on > PHP_Archive/Phar, that's very close to being attainable now in the physical > 'getting PECL'd extensions out to people' sense, but unless people are > running CLI or CGI or have access to their own php.ini they still can't do > much with those extensions. So we have to seriously consider how to > recommend extensions to hosts, other than by shipping them with the PHP > core. > 2) Maintenance status needs to be part of the equation. > 3) Stability needs to be part of the equation. > 4) Appropriateness to a given PHP branch needs to be part of the equation. > 5) CS and documentation need to be part of the equation. > Thoughts? > - Steph Best regards, Marcus --- ## #35119 — Marcus Boerger — 2008-02-02T23:22:29+00:00 URL: https://externals.io/message/35112#35119 · In reply to: #35114 Hello Pierre, basically you are saying that zip would not have been used by anybody if you hadn't forced us by mail bombardment to include it. So now I am wondering why you care so much what goes in and what goes out? After all it is the RMs decision. And we might get asked or not. marcus Saturday, February 2, 2008, 9:38:04 PM, you wrote: > > > […] > It is also possible to have both. It is even a good thing for what > linux distributions told me about zip. About moving all extensions to > PECL, we already discussed this problem and the conclusion was to > continue like now. There was good reasons listed. > Cheers, > -- > Pierre > http://blog.thepimp.net | http://www.libgd.org Best regards, Marcus --- ## #35121 — Pierre Joye — 2008-02-02T23:55:42+00:00 URL: https://externals.io/message/35112#35121 · In reply to: #35119 > basically you are saying that zip would not have been used by anybody if > you hadn't forced us by mail bombardment to include it. What are you talking about? I post one proposal and it was accepted after the only issue was resolved (which was a long discussions). You are getting ridiculuous with your attacks Marcus, and I stay polite. And no, it is not the RM decisions to choose what goes in or out, despite your changing opinions about open source, openness and PHP.net. > So now I am > wondering why you care so much what goes in and what goes out? After all it > is the RMs decision. And we might get asked or not. What I was refering to is the possibility to have releases via pecl.php.net and official PHP releases, on a regular basis. -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #35124 — Steph Fox — 2008-02-03T02:49:29+00:00 URL: https://externals.io/message/35112#35124 · In reply to: #35118 Hi Marcus, > what I want is php-src as minimum you can depend on. And php-default as > release managers playground. The RM can then say what he thinks is mature > enough to make it into a release. What _I_ want is a PHP core that is really core. By that I mean things like: date, spl, pcre, zlib, filter, simplexml, core-ish stuff such as PDO (no PDO drivers, unless we bundle SQLite as we could/should IMHO so there's a working DB for all), and underlying libs like libxml and mysqlnd that will make life easier for the many. I think what is distributed with PHP should be built-in and enabled by default, and it should include the basic essentials for making a simple website without anything else being added - and nothing more. Everything else - the fashionistas (JSON, xmlreader/writer) and the downright useful for some but not all (fileinfo, json, com_dotnet, posix) and the quirky stuff (pretty much anything Sara came up with) - should be in PECL. A release managers playground? Maybe we should look at PHP core + a 'recommended' PECL release that ships with it, and refer everyone to pecl.php.net/pecl4win.php.net for anything else. This assuming the problems I listed earlier are dealt with, natch. - Steph --- ## #35127 — Lester Caine — 2008-02-03T09:16:54+00:00 URL: https://externals.io/message/35112#35127 · In reply to: #35124 Steph Fox wrote: > Hi Marcus, > > > […] > > What _I_ want is a PHP core that is really core. By that I mean things > like: date, spl, pcre, zlib, filter, simplexml, core-ish stuff such as > PDO (no PDO drivers, unless we bundle SQLite as we could/should IMHO so > there's a working DB for all), and underlying libs like libxml and > mysqlnd that will make life easier for the many. I think what is > distributed with PHP should be built-in and enabled by default, and it > should include the basic essentials for making a simple website without > anything else being added - and nothing more. This opens another can of worms :( Why include installation specific stuff in the core. MySQL was dropped as the default for a reason lets not reintroduce it. Not bothering much WITH MySQL ( other than ensuring that SQL generated in my projects will still run on it ) I see that this new mysqlnd module is intended to SUPPORT PDO. Is THIS the way forward, building native drivers that can be used via PDO or is it just a another indication that one needs both PDO and a native driver? > Everything else - the fashionistas (JSON, xmlreader/writer) and the > downright useful for some but not all (fileinfo, json, com_dotnet, > posix) and the quirky stuff (pretty much anything Sara came up with) - > should be in PECL. > > A release managers playground? Maybe we should look at PHP core + a > 'recommended' PECL release that ships with it, and refer everyone to > pecl.php.net/pecl4win.php.net for anything else. > > This assuming the problems I listed earlier are dealt with, natch. > > - Steph -- Lester Caine - G8HFL ----------------------------- Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php --- ## #35130 — Lukas Kahwe Smith — 2008-02-03T09:56:08+00:00 URL: https://externals.io/message/35112#35130 · In reply to: #35127 > Steph Fox wrote: > > […] > > This opens another can of worms :( > Why include installation specific stuff in the core. MySQL was > dropped as the default for a reason lets not reintroduce it. > Not bothering much WITH MySQL ( other than ensuring that SQL > generated in my projects will still run on it ) I see that this new > mysqlnd module is intended to SUPPORT PDO. Is THIS the way forward, > building native drivers that can be used via PDO or is it just a > another indication that one needs both PDO and a native driver? I am also not sure if including mysqlnd in PHP core is the way to go. However I would not be generally opposed to including it in the PHP distribution. So just to make sure that this list is also aware of what has spawned out of the PDO discussion. One of the proposals has been to keep PDO driver development in PECL and therefore no CLA'ed stuff would be in php-src. The obvious problem is that currently PECL<>core do not really have the necessary concepts in place to make this happen, though the ideas necessary to make this work predate even PDOv1. Very long ago some people have formulated the vision that a PHP release would be similar to that of a Linux distribution. PHP core ~ Linux Kernel Various PECL extensions ~ Various OSS extensions Some Linux Distributions also go so far to include some closed source components. I doubt that we want to go there, but we might want to include CLA'ed stuff. However that is beyond the discussion of this thread. This thread is about discussing if there is a better way to handle PECL packages. Correct me if I am wrong or if I am missing something, but currently things work more or less like this. I think its important that we get an understanding of how things are right now and what the issues are, before we go off and solve them (maybe with the above mentioned approach): - most new extensions these days begin their life in PECL - generally PECL extensions are expected to follow internals CS (but they are not really checked if they do so) - most extensions are not dramatically changed before inclusion to fit PHP core, they either fit or they do not .. most extensions are actually either developed with the idea of eventually being included or they will most likely never make it into core (Steph already gave an example, that some PECL extensions tend to be much liberal with the use of Exceptions than is currently accepted in php-src) - if an extension is added to php-src, it is done through symlinking the PECL and php-src CVS - a few extension are also removed from php-src .. I am not quite sure how the process is there, but I presume the code is removed in php-src and checked into PECL CVS - ... (please complete this list) regards, Lukas --- ## #35132 — Marcus Boerger — 2008-02-03T11:24:35+00:00 URL: https://externals.io/message/35112#35132 · In reply to: #35130 Hello Lukas, Sunday, February 3, 2008, 10:56:08 AM, you wrote: > > > […] > I am also not sure if including mysqlnd in PHP core is the way to go. > However I would not be generally opposed to including it in the PHP > distribution. > So just to make sure that this list is also aware of what has spawned > out of the PDO discussion. One of the proposals has been to keep PDO > driver development in PECL and therefore no CLA'ed stuff would be in > php-src. The obvious problem is that currently PECL<>core do not > really have the necessary concepts in place to make this happen, > though the ideas necessary to make this work predate even PDOv1. > Very long ago some people have formulated the vision that a PHP > release would be similar to that of a Linux distribution. > PHP core ~ Linux Kernel > Various PECL extensions ~ Various OSS extensions > Some Linux Distributions also go so far to include some closed source > components. I doubt that we want to go there, but we might want to > include CLA'ed stuff. However that is beyond the discussion of this > thread. This thread is about discussing if there is a better way to > handle PECL packages. > - most new extensions these days begin their life in PECL MySQLND was the last extension started in php-src and I don't even remember when this was discussed (though in the current structure I like it there pretty much). Anyway my idea is to start everything in PECL and to to move everything out that can be moved out. And that includes all MySQL extensions as well as SQLite. Only this way people will use the PELC infrastructure. Otherwise we would just reduce functionality of PHP. And btw nearly all linux distributions today offer a bunch of PECL extensions, and for windows we offer DLLs for most PECL extensions for a long time now. marcus > - generally PECL extensions are expected to follow internals CS (but > they are not really checked if they do so) > - most extensions are not dramatically changed before inclusion to fit > PHP core, they either fit or they do not .. most extensions are > actually either developed with the idea of eventually being included > or they will most likely never make it into core (Steph already gave > an example, that some PECL extensions tend to be much liberal with the > use of Exceptions than is currently accepted in php-src) > - if an extension is added to php-src, it is done through symlinking > the PECL and php-src CVS > - a few extension are also removed from php-src .. I am not quite sure > how the process is there, but I presume the code is removed in php-src > and checked into PECL CVS We move the directory (or would drop the link). > - ... (please complete this list) > regards, > Lukas Best regards, Marcus --- ## #35133 — johannes@php.net — 2008-02-03T11:51:27+00:00 URL: https://externals.io/message/35112#35133 · In reply to: #35132 Hi, > MySQLND was the last extension started in php-src and I don't even remember > when this was discussed (though in the current structure I like it there > pretty much). Actually it was developed internally to MySQL and offered for inclusion when it was stable. So the PECL in that case was svn.mysql.com. I'll write about my opinion to the whole pecl<->core topic later (breakfast first) johannes --- ## #35135 — Steph Fox — 2008-02-03T17:24:58+00:00 URL: https://externals.io/message/35112#35135 · In reply to: #35132 Hi Marcus, > Anyway my idea is to start everything in PECL and > to to move everything out that can be moved out. And that includes all > MySQL > extensions as well as SQLite. Only this way people will use the PELC > infrastructure. Otherwise we would just reduce functionality of PHP. And > btw > nearly all linux distributions today offer a bunch of PECL extensions, and > for windows we offer DLLs for most PECL extensions for a long time now. The problem with this, as I wrote earlier, is that people relying on hosting can't use them, and hosts tend not to know as much as they could about PHP or its extensions. There does need to be a basic agreement here about what PHP is without any additions. IMHO that should be the minimum necessary to build a simple website, ie even if your host knows nothing about PHP it's still possible to do something useful with it. I suggested SQLite as a way of ensuring that there is _some_ database in PHP regardless of whether the host has added something or not. PDO should be built-in anyway. Neither is the case under doze @ present - both are separate entities that have to be explicitly enabled, i.e. there is no intrinsic database support in PHP. And yes, you do get Windows hosting these days. Also, we can't rely on linux distributions/the availability of DLLs on php.net for distribution. There needs to be a single simple cross-platform method for getting hold of extensions for PHP - but I think Greg's so close to achieving that, it isn't really an issue. The problem of zero QA, is. - Steph --- ## #35136 — Steph Fox — 2008-02-03T17:28:54+00:00 URL: https://externals.io/message/35112#35136 · In reply to: #35130 Hi Lukas, > Correct me if I am wrong or if I am missing something, but currently > things work more or less like this. I think its important that we get > an understanding of how things are right now and what the issues are, > before we go off and solve them (maybe with the above mentioned > approach): > - most new extensions these days begin their life in PECL > - generally PECL extensions are expected to follow internals CS (but > they are not really checked if they do so) > - most extensions are not dramatically changed before inclusion to fit > PHP core, they either fit or they do not .. most extensions are > actually either developed with the idea of eventually being included > or they will most likely never make it into core (Steph already gave > an example, that some PECL extensions tend to be much liberal with the > use of Exceptions than is currently accepted in php-src) > - if an extension is added to php-src, it is done through symlinking > the PECL and php-src CVS > - a few extension are also removed from php-src .. I am not quite sure > how the process is there, but I presume the code is removed in php-src > and checked into PECL CVS > - ... (please complete this list) - No QA. - Steph --- ## #35137 — Lukas Kahwe Smith — 2008-02-03T18:05:07+00:00 URL: https://externals.io/message/35112#35137 · In reply to: #35135 > Hi Marcus, > > > […] > > The problem with this, as I wrote earlier, is that people relying on > hosting can't use them, and hosts tend not to know as much as they > could about PHP or its extensions. There does need to be a basic > agreement here about what PHP is without any additions. IMHO that > should be the minimum necessary to build a simple website, ie even > if your host knows nothing about PHP it's still possible to do > something useful with it. I suggested SQLite as a way of ensuring > that there is _some_ database in PHP regardless of whether the host > has added something or not. PDO should be built-in anyway. Neither > is the case under doze @ present - both are separate entities that > have to be explicitly enabled, i.e. there is no intrinsic database > support in PHP. And yes, you do get Windows hosting these days. > > Also, we can't rely on linux distributions/the availability of DLLs > on php.net for distribution. There needs to be a single simple cross- > platform method for getting hold of extensions for PHP - but I think > Greg's so close to achieving that, it isn't really an issue. The > problem of zero QA, is. I am not sure if I misunderstood some other persons proposal, but at least my proposal was that the final thing we ship as version xyz of PHP would include a set of PECL extensions along with core that we deem as necessary for the bulk of our users solving the web problem. As such we could even publish a list of additional extensions we recommend to hosters to also install, though the question is if we can also QA them as part of the release process. regards, Lukas --- ## #35139 — Steph Fox — 2008-02-03T18:31:24+00:00 URL: https://externals.io/message/35112#35139 · In reply to: #35137 Hi Lukas, > I am not sure if I misunderstood some other persons proposal, but at > least my proposal was that the final thing we ship as version xyz of PHP > would include a set of PECL extensions along with core that we deem as > necessary for the bulk of our users solving the web problem. That's exactly what happens now, under doze at least. It doesn't solve the web problem because there are so many extensions shipped with the core. Every PHP release is accompanied by the core extensions and SAPIs as part of the core bundle, all PECL extensions available as a separate bundle, and absolutely no advice about the status of those extensions. > As such we could even publish a list of additional extensions we > recommend to hosters to also install, though the question is if we can > also QA them as part of the release process. I don't know if publishing a list would be half as useful as marking stuff 'stable', 'actively maintained'... if the pecl commands in the PEAR installer actually worked under doze, we could easily do all this. (It would be even better if you didn't actually need to install PEAR to use the PEAR installer.) - Steph > > regards, > Lukas --- ## #35148 — Marcus Boerger — 2008-02-03T20:45:59+00:00 URL: https://externals.io/message/35112#35148 · In reply to: #35137 Hello Lukas, same here. I proposed php-src with absolute minimum. And php-default as the release state. Where the RM has the last say in what goes in and what not. The rest of the discussion is once again how easy it is to get more than the default distribution onto hosters machines. But a) I couldn't care less, b) it is absolutely a discussion on its own and can addressed somewhere and somewhen else. marcus Sunday, February 3, 2008, 7:05:07 PM, you wrote: > > > […] > I am not sure if I misunderstood some other persons proposal, but at > least my proposal was that the final thing we ship as version xyz of > PHP would include a set of PECL extensions along with core that we > deem as necessary for the bulk of our users solving the web problem. > As such we could even publish a list of additional extensions we > recommend to hosters to also install, though the question is if we can > also QA them as part of the release process. > regards, > Lukas Best regards, Marcus --- ## #35147 — Steph Fox — 2008-02-03T20:56:20+00:00 URL: https://externals.io/message/35112#35147 · In reply to: #35148 Hi Marcus, > The rest of the discussion is once again how easy it is to get more than > the > default distribution onto hosters machines. But a) I couldn't care less, That's... a bit remiss of you :) b) > it is absolutely a discussion on its own and can addressed somewhere and > somewhen else. No, this is why I opened this thread. The 'somewhere and somewhen else' part has been the problem for the last years. - Steph --- ## #35149 — Pierre Joye — 2008-02-03T21:15:39+00:00 URL: https://externals.io/message/35112#35149 · In reply to: #35148 Hi, > same here. I proposed php-src with absolute minimum. And php-default as > the release state. Where the RM has the last say in what goes in and what > not. He can decide alone if something is stable enough to get in but he can't decide alone which features or extension is accepted or not. It was never the case and will hopefully never be the case. > The rest of the discussion is once again how easy it is to get more than the > default distribution onto hosters machines. But a) I couldn't care less, b) > it is absolutely a discussion on its own and can addressed somewhere and With the risk to repeat myself (and some other having said the same), the biggest advantage PHP has so far is that you get everything you may need with the default install. That's also why so many ISP does not provide anything else but what is enabled by default. It is yet another major mistake to try to solve the maintainance problem (or anything related to php extensions) without keeping this point in mind. If you don't care about what our users do with PHP, I miserably fail to see why we should listen your proposals. Which better place do you have in mind to discuss how to improve the way we distribute PHP and how to make the hosting companies and system administrators life easier than on internals? -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #35150 — Steph Fox — 2008-02-03T21:21:22+00:00 URL: https://externals.io/message/35112#35150 · In reply to: #35149 > With the risk to repeat myself (and some other having said the same), > the biggest advantage PHP has so far is that you get everything you > may need with the default install. This hasn't been true of the Windows distribution for the last few years. I think it should be - I think the default install under doze should offer the same as the default install everywhere else. Outside of any other considerations, think of all those poor PHP newbies testing out a default install locally and then howling that SQLite doesn't work. Most of the help forums will tell them they have it installed - but they don't. They have it *available*, which is not the same thing. - Steph --- ## #35151 — Pierre Joye — 2008-02-03T21:22:57+00:00 URL: https://externals.io/message/35112#35151 · In reply to: #35150 > > […] > > This hasn't been true of the Windows distribution for the last few years. Good point but I admit that I never understood why our windows releases have been so different from the source releases, from a configuration point of view. Many default extensions are (were) not enabled. But that's not a big problem and can be easily fixed no? :) -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #35152 — Steph Fox — 2008-02-03T21:27:44+00:00 URL: https://externals.io/message/35112#35152 · In reply to: #35151 > Good point but I admit that I never understood why our windows > releases have been so different from the source releases, from a > configuration point of view. Many default extensions are (were) not > enabled. But that's not a big problem and can be easily fixed no? :) It's not a big problem so long as everyone agrees on what should be enabled by default. Assuming the aim is to have everything _not_ enabled by default move to PECL, that's quite a big deal. - Steph --- ## #35153 — Pierre Joye — 2008-02-03T21:31:37+00:00 URL: https://externals.io/message/35112#35153 · In reply to: #35152 > > […] > > It's not a big problem so long as everyone agrees on what should be enabled > by default. What should be enabled by default on windows should be the same as on linux (and the windows specific extensions like com), imho. > Assuming the aim is to have everything _not_ enabled by default move to > PECL, that's quite a big deal. That's another topic and I tend to disagree (more later on that). -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #35154 — Steph Fox — 2008-02-03T21:44:57+00:00 URL: https://externals.io/message/35112#35154 · In reply to: #35153 > > […] > > That's another topic and I tend to disagree (more later on that). I'll wait... but I suspect all the arguments against that are based on PECL as it currently is, with all its distribution problems et al. - Steph --- ## #35159 — Jani Taskinen — 2008-02-04T09:18:24+00:00 URL: https://externals.io/message/35112#35159 · In reply to: #35118 I'd like everything in PECL. Even the core. And yes, it is quite doable. --Jani > Hello Steph, > > what I want is php-src as minimum you can depend on. And php-default as > release managers playground. The RM can then say what he thinks is mature > enough to make it into a release. > > marcus > > Saturday, February 2, 2008, 9:14:12 PM, you wrote: > > > […] > > > […] > > > […] > > > […] > > > […] > > > […] > > > […] > > > […] > > > […] > > > […] > > > > > Best regards, > Marcus > -- Patches/Donations: http://pecl.php.net/~jani/ --- ## #35160 — Jani Taskinen — 2008-02-04T09:24:37+00:00 URL: https://externals.io/message/35112#35160 · In reply to: #35130 > I am also not sure if including mysqlnd in PHP core is the way to go. > However I would not be generally opposed to including it in the PHP > distribution. There's a technical reason for that: It needs to be statically buildin to work properly. Same reason why ext/libxml is there actually. --Jani --- ## #35165 — Derick Rethans — 2008-02-04T09:31:20+00:00 URL: https://externals.io/message/35112#35165 · In reply to: #35112 > 1) Distribution woes need to end. With the work Greg's been doing lately on > PHP_Archive/Phar, that's very close to being attainable now in the physical > 'getting PECL'd extensions out to people' sense, but unless people are running > CLI or CGI or have access to their own php.ini they still can't do much with > those extensions. So we have to seriously consider how to recommend extensions > to hosts, other than by shipping them with the PHP core. > > 2) Maintenance status needs to be part of the equation. > > 3) Stability needs to be part of the equation. > > 4) Appropriateness to a given PHP branch needs to be part of the equation. > > 5) CS and documentation need to be part of the equation. > > Thoughts? Yeah, my main concern is actually not with the one above, except for 2) perhaps. The brilliant thing to have everything in core, is that it gets checked out, updated, etc like all other standard parts. Becaus of this compile errors and other related issues are *quickly* discovered - this is especially important when it comes to OS-differences. regards, Derick --- Next page: https://externals.io/message/35112.md?page=2