"pyrus make" create invalid nested test filelist at package_compatible.xml

[sasezaki]

command pyrus make
creates unexpected filelist at package_compatible.xml, if "tests" directory exists.

Here is my package repositories & package_compatible.xml.
https://github.com/diggin/Diggin_Http_Charset
https://github.com/diggin/Diggin_Http_Charset/blob/master/package_compatible.xml

in package_compatible.xml -> phprelease -> filelist,

"test/pear.diggin.musicrider.com/Diggin_Http_Charset/Diggin/Http/Charset/Converter/Diggin/Http/Charset/Converter/FixedfromConverterTest.php"

so If I try install by pear, got error.

ERROR: file /tmp/pear/temp/tmpE4SgB6/Diggin_Http_Charset-0.1.0/test/pear.diggin.musicrider.com/Diggin_Http_Charset/Diggin/Http/Charset/Front/Diggin/Http/Charset/Front/UrlRegexTest.php does not exist

(I use pyrus according this guideline.
https://github.com/pyrus/Pyrus/wiki/Developing-for-Pyrus )

[saltybeagle]

I can reproduce the errors you're seeing — so currently pyrus cannot create a compatible package for pear if the tests directory exists.

Are the paths simply wrong? I wonder if the channel name simply needs to be omitted for the compatible package.xml.

[fpoirotte]

Isn't this the same as pyrus/Pyrus#26 (which was opened for the data/ folder, but it was later noted that the issue also affects docs/ & test/).

[boenrobot]

Can anyone (@saltybeagle, @cellog ?) tell me what are supposed to be the differences between a compatible package.xml and a normal package.xml?

I've successfully had all of my packages use the normal package.xml, declare PEAR 1.4 as the minimum required PEAR installer, and they all install fine on both Pyrus and PEAR... So I can't seem to get what's the intention...

If there isn't a difference YET, and the intention is forwards compatibility (i.e. IF the format of package.xml is changed), perhaps for now, "pyrus make" could be changed to just copy the package.xml file at the end with that other name? In the event of a format change, we could then modify the copy to alter the original in whatever fashion is not compatible with the next package.xml format.

[cellog]

The way the nested DIR and file tags are parsed is different in the two
installers, so the install locations end up being different.
On Jul 31, 2014 12:38 PM, "Vasil Rangelov" [email protected] wrote:

Can anyone (@saltybeagle https://github.com/saltybeagle, @cellog
https://github.com/cellog) tell me what are supposed to be the
differences between a compatible package.xml and a normal package.xml?

I've successfully had all of my packages use the normal package.xml,
declare PEAR 1.4 as the minimum required PEAR installer, and they all
install fine on both Pyrus and PEAR... So I can't seem to get what's the
intention...

If there isn't a difference YET, and the intention is forwards
compatibility (i.e. IF the format of package.xml is changed), perhaps for
now, "pyrus make" could be changed to just copy the package.xml file at the
end with that other name? In the event of a format change, we could then
modify the copy to alter the original in whatever fashion is not compatible
with the next package.xml format.

—
Reply to this email directly or view it on GitHub
#14 (comment)
.

[boenrobot]

An example?

[cellog]

I have not tested this since I wrote it, but there should be a test case
for both, look for a skip if section that skips for old installer and runs
for new
On Aug 1, 2014 4:46 PM, "Vasil Rangelov" [email protected] wrote:

An example?

—
Reply to this email directly or view it on GitHub
#14 (comment)
.

[boenrobot]

There's certainly not one in Pyrus_Developer... I searched in Pyrus too, and there's nothing of the sort there either.

Searching for "SKIPIF" in the "tests" dir shows a lot of files that would skip because of OpenSSL or Windows, and only one test (upgradeRegistry.phpt) that skips if PEAR1 is missing, but runs if it IS there (so... the very opposite of what you're saying...).

There's also one test (iscompatible.basic.phpt) that basically shows when is a package "detected" as compatible... and I must say I don't get the logic in there too... but it doesn't illustrate the supposed difference in terms of how PEAR and Pyrus would interpret a package file differently.

[cellog]

Simple solution: install from a new package.xml with both and see the
differences in where data files are installed
On Aug 2, 2014 10:30 AM, "Vasil Rangelov" [email protected] wrote:

There's certainly not one in Pyrus_Developer... I searched in Pyrus too,
and there's nothing of the sort there either.

Searching for "SKIPIF" in the "tests" dir shows a lot of files that would
skip because of OpenSSL or Windows, and only one test
(upgradeRegistry.phpt) that skips if PEAR1 is missing, but runs if it
IS there (so... the very opposite of what you're saying...).

There's also one test (iscompatible.basic.phpt) that basically shows when
is a package "detected" as compatible... and I must say I don't get the
logic in there too... but it doesn't illustrate the supposed difference in
terms of how PEAR and Pyrus would interpret a package file differently.

—
Reply to this email directly or view it on GitHub
#14 (comment)
.

[boenrobot]

The only difference I see is that in PEAR, the root of a package's data dir (relative to the "main" data dir) is just the package name, while in Pyrus, it's the channel, and then in a subfolder, the package name.

But that doesn't seem to be related to having or not having nested "dir" and "file" elements in the package.xml. Or at least I can't seem to notice the relation.

A package that wishes to be compatible with both Pyrus and PEAR would need to address this in it's application code, and not in package.xml, since you're always just getting the main data dir, yet the installer (be it PEAR or Pyrus) will always create a package root in its own fashion.