RE : Extending include path to support stream wrappers

Thanks for your answer, I have been searching for an alternate way for more than one month now but I still don't see any way to resolve the problem of relative includes in packaged files. The goal, here, is to package an existing software with as few modifications as possible. It is the only way to have software teams adopt the package's format. And, when the software's author is OK to make his source compatible with the package system's requirement, his source files must be included without any modification. Setting a 'phar://' prefix on every file access everywhere does not really fit this constraint. If the code cannot be made compatible, as nobody wants to maintain and support two sets of sources, it is practically impossible to distribute both formats at the same time. I am not sure it is the best way to promote a new package system to the developers. Anybody having replaced every relative URLs in phpMyAdmin knows what I am talking about. I wanted to try it myself: I spent three hours on it yesterday and I still have errors. And, now, what can I do with it ? If I distribute it, who will accept to use it in a production environment ? The only alternative I found was to prefix every relative paths with 'dirname (_FILE_).DIRECTORY_SEPARATOR', but it works only for paths relative to the including file's directory, and once again, I don't think it would be a good argument to give to developers. I am sorry but, be it PHAR or another one, I humbly think we have a potential problem with the packaging process in general. If somebody has an idea to solve it without modifying the code, I'd really like to hear from him. Regards Francois -----Original Message----- From: Sara Golemon [mailto:pollita@php.net] Sent: Tuesday, July 11, 2006 4:29 PM To: LAUPRETRE François (P) Cc: internals@lists.php.net Subject: Re: Extending include path to support stream wrappers > But, once again, may I humbly ask you to > focus on my primary question, instead of > arguing about a potential alternative to PHAR. > And I also repeat that my question is of > great interest for PHAR too. > I think it's an interresting, yet ultimately inefficient idea. I would recommend that if you *really* need this functionality, that you first rethink what you're trying to accomplish. If you still havn't changed your mind there are a couple approaches you could take to handling this within your script rather than modifying core. -1 -Sara