Links to know about
Music
The Chiara String Quartet
Chiara Quartet (MySpace)
Greenwood Music Camp
UNL School of Music
PHP
PEAR Installer Manifesto
phpDocumentor
PEAR
phar
docblock
PHP_Parser
PHP_Parser_DocblockParser
PHP_ParserGenerator
PHP_LexerGenerator
PEAR_PackageFileManager
PHP_Archive
Games_Chess
Blogs
Joshua Eichorn
Paul M. Jones
Davey Shafik
Popular Entries
Setting up your own PEAR channel with Chiara_PEAR_Server - the official way
(28)
Do you develop a website? It is infinitely better to synchronize live and development sites using the PEAR Installer(25)
doing the PEAR thing(19)
Using PEAR 1.4.0 to install PEAR packages on a remote host(19)
PEAR now fits in a bottle: meet go-pear.phar(17)
Categories
Syndicate This Blog
Powered by
Monday, September 19. 2005
Confusions about PEAR 1.4.0 and PECL
Comments
Display comments as
(Linear | Threaded)
So why have you and Pierre been pushing us to use the new file format?
Any why isn't there auto-conversion from one version of the file format to the other?
Any why isn't there auto-conversion from one version of the file format to the other?
I believe that your first question is answered by #2 above. If you don't feel this answers the question, then please ask more specific questions.
Let me pose a question to you: why is there no auto-conversion of PHP 4 scripts to PHP 5 scripts, or PHP 5 scripts to PHP 4 scripts? This is the same kind of question. PHP 5, although similar to PHP 4, is a different language, and if you try to downgrade PHP 5-based scripts to PHP 4, it is a tricky process. Upgrading PHP 4 to PHP 5 script syntax automatically involves a certain amount of risk as some assumptions need to be made about member visibility in classes, for instance. And yes, a lot of PHP 4-based scripts don't work in PHP 5, I know because about 70% of the scripts I have been using don't work in PHP 5.
There is a "pear convert" command, but this makes some incredibly risky assumptions, and also will try to convert *invalid* package.xml 1.0 (with missing packages leads, etc.) into a valid package.xml 2.0 with more assumptions. In addition, the dependency format of package.xml 1.0 allowed some weird things like optional PHP dependencies that simply don't translate into package.xml 2.0 format.
The fact is, you *can* create package.xml 2.0 from package.xml 1.0, it is just that although the generated file is guaranteed to be valid, it is *not* guaranteed to be correct, because of assumptions. All you need to do is look through the generated package.xml and make sure it looks good.
There is also a hackish way to convert from package.xml 2.0 to package.xml 1.0, but this is even worse, as it completely ignores a large range of important data, like the install-as tag and platform-specific things.
Basically, I spent several months trying to get this conversion working properly, and it is pretty good, but certainly does not come close to the certainty you get from using PEAR_PackageFileManager scripts. When you use this script, you are guaranteed to get both a valid and a logical package.xml.
This is all I have been saying.
Let me pose a question to you: why is there no auto-conversion of PHP 4 scripts to PHP 5 scripts, or PHP 5 scripts to PHP 4 scripts? This is the same kind of question. PHP 5, although similar to PHP 4, is a different language, and if you try to downgrade PHP 5-based scripts to PHP 4, it is a tricky process. Upgrading PHP 4 to PHP 5 script syntax automatically involves a certain amount of risk as some assumptions need to be made about member visibility in classes, for instance. And yes, a lot of PHP 4-based scripts don't work in PHP 5, I know because about 70% of the scripts I have been using don't work in PHP 5.
There is a "pear convert" command, but this makes some incredibly risky assumptions, and also will try to convert *invalid* package.xml 1.0 (with missing packages leads, etc.) into a valid package.xml 2.0 with more assumptions. In addition, the dependency format of package.xml 1.0 allowed some weird things like optional PHP dependencies that simply don't translate into package.xml 2.0 format.
The fact is, you *can* create package.xml 2.0 from package.xml 1.0, it is just that although the generated file is guaranteed to be valid, it is *not* guaranteed to be correct, because of assumptions. All you need to do is look through the generated package.xml and make sure it looks good.
There is also a hackish way to convert from package.xml 2.0 to package.xml 1.0, but this is even worse, as it completely ignores a large range of important data, like the install-as tag and platform-specific things.
Basically, I spent several months trying to get this conversion working properly, and it is pretty good, but certainly does not come close to the certainty you get from using PEAR_PackageFileManager scripts. When you use this script, you are guaranteed to get both a valid and a logical package.xml.
This is all I have been saying.
Let's assume that we have valid package.xml files (because we do).
Can we have pear package auto-generate package2.xml?
I really want to avoid the requirement for learning yet-another-file-format. If developers are sitting there comparing two xml files against each other and scratching around DTDs, we've done something wrong with our packaging tools.
What I want, as I keep saying, is 1 file to describe the package and a single command line invocation to create it.
This is what we have today; anything else is making things harder, with no clear reasoning behind it.
I'll say it again: there is no logical reason why we can't auto-generate one version of the package.xml file from the other, given that they describe the *same* package.
The tools should be able to do a better job at this than humans--isn't that part of the point behind XML anyway?
Can we have pear package auto-generate package2.xml?
I really want to avoid the requirement for learning yet-another-file-format. If developers are sitting there comparing two xml files against each other and scratching around DTDs, we've done something wrong with our packaging tools.
What I want, as I keep saying, is 1 file to describe the package and a single command line invocation to create it.
This is what we have today; anything else is making things harder, with no clear reasoning behind it.
I'll say it again: there is no logical reason why we can't auto-generate one version of the package.xml file from the other, given that they describe the *same* package.
The tools should be able to do a better job at this than humans--isn't that part of the point behind XML anyway?
Wez, this has gone on long enough.
There *IS* 1 file and a single command. If you use package.xml 2.0,
$ pear package
will generate the package. The only thing you are doing by this is requiring PEAR 1.4.0
Why is this so difficult? You require PHP 5.0 for PDO - and I imagine if you had to support PHP 4 it would be terrible.
Simply put: if you don't need the features of package.xml 2.0, you don't need to use it right away. If you do, - AND PDO DOES - then you should use it exclusively. I just can't fathom why you claim there is no clear reasoning less than 2 inches of reading space beneath the clearest reasoning I can see. Did you even *READ* the post?? I guess not. Let me try again with other wording:
Right now, there is a stupid message in your release notes that tells people to unload PDO/PDO drivers from php.ini before upgrading. This requires completely unnecessary work just to upgrade the thing. Disabling PDO in php.ini on a live website is a major production. You can't expect this will be a good thing. People who are willing to go through that kind of work just to upgrade PDO will be more than willing to upgrade their PEAR to a MORE STABLE VERSION to avoid that work.
XML can be converted to other formats, but you can't ask a computer to magically create more information than is contained in the file. You know this, why do you make me tell you?
Wez, what is the problem? PDO isn't even *stable* yet, you are not going to hurt people by requiring PEAR 1.4. PEAR 1.4 will be distributed with PHP 5.1, this is not a crisis, you are just making a wildfire out of irrational unnecessary fears.
No, what you are saying is that you're afraid of things breaking by switching to package.xml 2.0. Yet, you refuse to even consider investigating the format to see if it in fact better. This is unlike you, Wez. I have spent YEARS working on this to make it solve problems that you yourself spoke to me about in PECL.
My interest is in improving PHP and PECL by making it possible for more people to actually install and maintain extensions separate from the bloated PHP distribution.
Let's face it: PEAR 1.3.x had major problems with distributing PDO. The PDO package is large and complex, and the first PECL package that can claim this fact. You had to go into PEAR_Builder and rewrite some code just to make it install properly.
There *IS* 1 file and a single command. If you use package.xml 2.0,
$ pear package
will generate the package. The only thing you are doing by this is requiring PEAR 1.4.0
Why is this so difficult? You require PHP 5.0 for PDO - and I imagine if you had to support PHP 4 it would be terrible.
Simply put: if you don't need the features of package.xml 2.0, you don't need to use it right away. If you do, - AND PDO DOES - then you should use it exclusively. I just can't fathom why you claim there is no clear reasoning less than 2 inches of reading space beneath the clearest reasoning I can see. Did you even *READ* the post?? I guess not. Let me try again with other wording:
Right now, there is a stupid message in your release notes that tells people to unload PDO/PDO drivers from php.ini before upgrading. This requires completely unnecessary work just to upgrade the thing. Disabling PDO in php.ini on a live website is a major production. You can't expect this will be a good thing. People who are willing to go through that kind of work just to upgrade PDO will be more than willing to upgrade their PEAR to a MORE STABLE VERSION to avoid that work.
XML can be converted to other formats, but you can't ask a computer to magically create more information than is contained in the file. You know this, why do you make me tell you?
Wez, what is the problem? PDO isn't even *stable* yet, you are not going to hurt people by requiring PEAR 1.4. PEAR 1.4 will be distributed with PHP 5.1, this is not a crisis, you are just making a wildfire out of irrational unnecessary fears.
No, what you are saying is that you're afraid of things breaking by switching to package.xml 2.0. Yet, you refuse to even consider investigating the format to see if it in fact better. This is unlike you, Wez. I have spent YEARS working on this to make it solve problems that you yourself spoke to me about in PECL.
My interest is in improving PHP and PECL by making it possible for more people to actually install and maintain extensions separate from the bloated PHP distribution.
Let's face it: PEAR 1.3.x had major problems with distributing PDO. The PDO package is large and complex, and the first PECL package that can claim this fact. You had to go into PEAR_Builder and rewrite some code just to make it install properly.
The point you're missing is that I'm not even talking specifically about PDO.
We don't mind upgrading to package2.xml, but we *need* to eliminate this 2-file problem for the packages (and that's most of them) that still need to run on older PHP/PEAR combinations.
Automating the creation of one of those files is the best solution, and I'm trying to find out why we can't have that.
From a professional perspective, the release process needs to be made as simple as possible. This isn't about the effort of typing stuff over and over so much as the increased risk of forgetting to type something, typing something wrong, or copy-and-paste errors.
All my comments on this matter are coming from my professional experiences in release engineering. Rather than trying to belittle my comments by crying FUD, why can't you listen to them? You may have been working on this new PEAR release for years (and well done!) but I've been working in commercial software development for longer; I honestly believe you have something to gain from my experience.
We don't mind upgrading to package2.xml, but we *need* to eliminate this 2-file problem for the packages (and that's most of them) that still need to run on older PHP/PEAR combinations.
Automating the creation of one of those files is the best solution, and I'm trying to find out why we can't have that.
From a professional perspective, the release process needs to be made as simple as possible. This isn't about the effort of typing stuff over and over so much as the increased risk of forgetting to type something, typing something wrong, or copy-and-paste errors.
All my comments on this matter are coming from my professional experiences in release engineering. Rather than trying to belittle my comments by crying FUD, why can't you listen to them? You may have been working on this new PEAR release for years (and well done!) but I've been working in commercial software development for longer; I honestly believe you have something to gain from my experience.
We can all learn from each other. What I've been trying to tell you is that your concerns do not have merit. Actually trying out the installer will verify my assertions.
You may have more release engineering experience, but I have more PEAR installer experience, and I am telling you: the thing already answers every point and fear that you have raised in your post and on my blog.
Even so, I am trying to find a better way to do things. All I ask is that instead of posting incendiary public posts, you try working with me on the solution.
If you forget to copy something from one package.xml to the other, packaging will fail. It will not allow you to release a package with conflicting package.xmls.
The process of determining equivalency can be made better, probably, but what I am trying to tell you is that the "pear package" command does not allow you to make cut-and-paste or "forgot to add it" errors. If you forget to add anything to *either* package.xml that is another story.
Let's get down to business. Would you please try to easily outwit the "pear package" command?
With any extension in pecl, try these steps:
$ pear convert
$ pear package
Then, change one of the tags in package.xml. The maintainers, the package name, the version - anything that is used by the installer itself to install the package.
See if it still allows you to package.
If you find issues, then we can talk. Otherwise, I would like to request respectfully that you try out running pear convert/pear package for a release or two and see if it doesn't work fantastically. If not, we can talk again.
I've thought a LOT more about how to solve this exact problem of double packaging than you have to date, and I really would like the benefit of the doubt until there is some hard evidence backing up your claims of bad design.
You may have noticed I have already fixed pecl-related issues you encountered less than 24 hours ago. You can rest assured this behavior (bug found - kill now) will continue unabated until PEAR works perfectly for PECL. You have my word on that. Now let's start working in harmony.
You may have more release engineering experience, but I have more PEAR installer experience, and I am telling you: the thing already answers every point and fear that you have raised in your post and on my blog.
Even so, I am trying to find a better way to do things. All I ask is that instead of posting incendiary public posts, you try working with me on the solution.
If you forget to copy something from one package.xml to the other, packaging will fail. It will not allow you to release a package with conflicting package.xmls.
The process of determining equivalency can be made better, probably, but what I am trying to tell you is that the "pear package" command does not allow you to make cut-and-paste or "forgot to add it" errors. If you forget to add anything to *either* package.xml that is another story.
Let's get down to business. Would you please try to easily outwit the "pear package" command?
With any extension in pecl, try these steps:
$ pear convert
$ pear package
Then, change one of the tags in package.xml. The maintainers, the package name, the version - anything that is used by the installer itself to install the package.
See if it still allows you to package.
If you find issues, then we can talk. Otherwise, I would like to request respectfully that you try out running pear convert/pear package for a release or two and see if it doesn't work fantastically. If not, we can talk again.
I've thought a LOT more about how to solve this exact problem of double packaging than you have to date, and I really would like the benefit of the doubt until there is some hard evidence backing up your claims of bad design.
You may have noticed I have already fixed pecl-related issues you encountered less than 24 hours ago. You can rest assured this behavior (bug found - kill now) will continue unabated until PEAR works perfectly for PECL. You have my word on that. Now let's start working in harmony.
Ok .. I think the key point is that Greg says that package2.xml will fix the following note:
"You should uninstall and re-install your individual database drivers whenever you upgrade the base PDO package, otherwise you will see an error about PDO API numbers when you run your PHP scripts."
While Wez appearently does not think it would fix this issue. At the same time pecl.php.net uploads that do not contain a package2.xml were issueing a warning (until Wez disabled this). This being what spawn the initial sound off by Wez about being pushed to use package2.xml. Why was this put in? I thought pecl packages would generally work just fine with the old package.xml unless they need funky tricks like pdo.
So my questions are:
1) why was there a warning added for packages without a package2.xml on upload in pecl.php.net?
2) could someone verify that package2.xml does infact rid pdo of said unloading issue?
"You should uninstall and re-install your individual database drivers whenever you upgrade the base PDO package, otherwise you will see an error about PDO API numbers when you run your PHP scripts."
While Wez appearently does not think it would fix this issue. At the same time pecl.php.net uploads that do not contain a package2.xml were issueing a warning (until Wez disabled this). This being what spawn the initial sound off by Wez about being pushed to use package2.xml. Why was this put in? I thought pecl packages would generally work just fine with the old package.xml unless they need funky tricks like pdo.
So my questions are:
1) why was there a warning added for packages without a package2.xml on upload in pecl.php.net?
2) could someone verify that package2.xml does infact rid pdo of said unloading issue?
Wez may not have had occasion to try fixing this issue with the solution I describe in this post.
The only situation by which installing a PDO driver would fail is if PDO is the built-in version and a new shared driver is being added later. This, however, can be done easily via:
$ pear install pecl/PDO_driver
as the pear command uses php.ini, which would have php_pdo.so/dll loaded, and therefore would work.
I have to run, so I will answer the rest of the comment when I have a chance.
The only situation by which installing a PDO driver would fail is if PDO is the built-in version and a new shared driver is being added later. This, however, can be done easily via:
$ pear install pecl/PDO_driver
as the pear command uses php.ini, which would have php_pdo.so/dll loaded, and therefore would work.
I have to run, so I will answer the rest of the comment when I have a chance.
Links in this article
PEAR Installer Manifesto
Calendar
|
November '08 |
|
||||
| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
Quicksearch
My Latest Releases
Top Exits
pear.php.net (305)
www.php.net (86)
pear.chiaraquartet.net (79)
pecl.php.net (58)
news.php.net (43)
www.php.net (86)
pear.chiaraquartet.net (79)
pecl.php.net (58)
news.php.net (43)
Just a few moments ago, I released PEAR 1.4.1 at pear.php.net. This is not just your typical bugfix release, some issues that have been around for a long time have finally been fixed. I'm very excited about this release, and look forward to hearing fe
Tracked: Sep 25, 14:02