Re: exploring include_path options for pecl/phar

Hi Greg,

The only problem I can see with it is that it presumably means you'll need ext/phar enabled before you can use any pharballed application that isn't entirely standalone, is that correct? or could this interception magic be integrated into the default stub?

The interception magic will not work without pecl/phar. If you want your app to work without pecl/phar, then you need to have an if/else.

if/else what? sorry that went over my head for the time being... So basically we'd be losing the "run anywhere" aspect in order to gain the "run anything" aspect, and also presumably we'd be losing the ability to run certain phars on earlier versions of PHP altogether. I don't know how good a solution this is; '.phar' is already widely understood to mean an archive that can be opened with pure PHP, thanks mainly to its provenance in PHP_Archive. Maybe we should have a different name for files that need such special consideration - .pharx or something - and keep plain .phar for less complicated stuff. (Not pharts - you already said that was for bugs ;) Would that make the concept harder to grasp for the end user? I don't know, but I know for sure that _not_ marking files that need the extension in a very obvious way is likely to be problematic. Apart from those considerations, I agree it's the best proposal on the table. NB I'd also like to revisit phar.zip/tar at some point soon - I've a mini-proposal you'll either love or hate. - Steph