Re: Re: cvs: pecl /phar phar.c

Hi Greg,

The file in question that I was trying to manipulate was named zfapp.phar.tar.php - it's clearly a phar in waiting. Additionally, the only thing that is absolutely required of a phar archive in zip or tar format in order for it to be executable is that it contain "phar" in the name.

It didn't have a stub, is why. In other words - regardless of its name - it was a plain tarball.

The way you have designed the conversion/opening code, there was no way to create a tar-based or zip-based phar archive, except via making a phar, and then converting it to a zip/tar, which is awkward at best.

Huh? You could do new Phar('xxx.phar.zip') and it worked.

The original intention was to enforce naming for phar archives, and to act differently when readonly is enabled. Our goal must be simplicity whenever possible.

I don't know if it's that simple to say 'a tar is a tar unless this INI setting is on'. I thought once a tar, always a tar unless explicitly converted. (I'm talking about plain tarballs here, not phar.tar.)

Basically phar.readonly=1 means we are very strict about enforcing these things: 1) no creation/modification of phar file format archives whatsoever check

2) no opening tar/zip-based phar archives with PharData class check

3) no opening data tar/zip-based archives with Phar class check

4) creation/modification of tar/zip-based archives with PharData class is allowed check

5) conversion of phar/tar/zip-based phars to PharData tar/zip without stub/alias is allowed, but the filename cannot contain ".phar"

right, we don't have this implemented yet (even in the original disaster area) but it makes sense

phar.readonly=0 means these criteria: 1) phar file format archives can be created without restriction check

2) any format can be converted to any other format, including phar/tar/zip-based phars to PharData tar/zip without stub/alias and vice-versa

Coo, you don't want much.. :)

3) all phar archives created in tar/zip file format MUST contain "phar" in the filename

Phar archives (Phar objects named .phar.tar), yes - not tar archives (PharData objects named .tar).

4) all pre-existing tar/zip archives modified via Phar class automatically have a stub added if and ONLY if the filename contains "phar"

We disagree over this... in fact you're disagreeing with earlier plans too here. No plain tar/zip archive was supposed to automatically have a stub added... that's where we're conflicting in terms of expected behaviour.

5) data tar/zip are files without "phar" in the name, and cannot be opened without renaming or conversion from PharData

Huh? (I think we have different understanding of 'opened' here.)

Previous to my commit, there was no way to convert a data-based tar/zip into a phar archive, which was never the intention.

Actually I left convertToPhar() open to PharData objects for that express purpose (when readonly=0). That's why that test was changed to allow it.

In other words, here is the API I'd like to see: Phar->convert() PharData->convert()

<snipping the allowed conversions lists for the sake of brevity />

the compressAllFiles*() methods would return to working as they did in 1.X, which is to say they would operate on each file iteratively within the phar archive, in order to compress all files in a zip archive, for instance. They would throw an exception for tar archive because there is no way to compress files within a tar.

Is there anything other than a .phar.zip that would use this?

The sheer number of possible conversions precludes using convertTo*() methods. Simpler is going to be far better here.

I think that _is_ simple from the user's perspective - what makes it un-simple is the possibility of tar -> phar.tar.

Constants needed: Phar::PHAR Phar::TAR Phar::ZIP Phar::DATA Phar::GZ Phar::BZ2 Phar::UNCOMPRESS For my example (taking a pre-existing tar with ".phar" in the name and converting it to phar.tar), the code would look something like:

You shouldn't be able to do this. We even _agreed_ you shouldn't be able to do this. If it doesn't have a stub it's a straight tarball, regardless of its name. <snip examples to keep length of post down /> I seriously think it's a better idea to force an explicit conversion to Phar from PharData objects and vice versa, it would make the whole API much more straightforward from a usage perspective. convertToTar() and convertToZip() would return either phar.tar/tar (with or without compression via Phar::BZ2/GZ argument) or phar.zip/zip, depending on the type of object they were passed. convertToPhar() and convertToPharData() would take PharData and Phar types respectively and return the equivalent (e.g. $zip = convertToPharData('my.phar.zip');). The only way to get a pure Phar would be via the constructor. Can I try it my way and show you what I mean? (Maybe in a CVS branch?) - Steph

Greg -- PECL development discussion Mailing List (http://pecl.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php