Re: exploring include_path options for pecl/phar

Steph Fox wrote: >> 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. > > ... unless it's possible for the default stub to 'know' when it's > being faced with stuff it can't cope with and die with an explanation > on its lips. In which case, ignore my earlier musings. > > - Steph (really not thinking straight today) Hi again, Actually, to tell the truth, on further reflection, I can't see how this will be a problem. Why? Most applications use set_include_path()/ini_set() with either 1) some form of dirname(__FILE__) to locate stuff 2) "." to refer to the current directory. Those using #1 will work because when executed inside a phar, it will use phar://<path/to/phar>, and those using #2 will work because . is always set to the right location if we started inside a phar. In truth, only application start points rely upon ".", and so only the most poorly written apps would need modification to work in or outside of a phar without change. I think I've found the magic bullet. Greg