LAUPRETRE François (P) wrote: > Hello, > > I am currently implementing a packaging tool in PHP. If you know PHAR, it is > the same kind of tool, which allows to implement a virtual file tree in a > single physical file. > > In such a tool, every file path becomes a 'stream-wrapped' path and the > problem comes from the difference in the way PHP handles these paths > relatively to 'plain' paths, especially the fact that a 'stream-wrapped' path > cannot be part of the include path. > > The first reason is that the ':' character is used by the stream wrapper and, > also, as the Unix path separator. This one would be easy to solve, but it > would be useless because the engine dispatches its 'open' requests to the > wrappers before searching through the include paths. And, the include path is > searched in the 'plain' wrapper code. > > I have proposed some ideas to correct this behavior as a 'Feature request' at > http://bugs.php.net/bug.php?id=38006. Could you please comment on it ? Even > if you think that it is total nonsense or a loss of time, I would really > appreciate to have your opinion on this subject before starting to modify > anything. > > Thanks & regards > > François > > PS: If we can solve this issue, I have the same for you (maybe more complex) > about stream wrapper support in chdir/getcwd, and then the glob/fnmatch issue > ;-)
allowing stream wrappers in include_path will open a potentially gigantic security hole, making sure that it is closed will be a huge challenge, and introduce a bit of overhead. In terms of what choices you have with pecl/phar and libraries, the best way to handle this is to use relative includes (require_once "phar://lib.phar/File.php") and have the user either include all the necessary phars in their php script or define an autoload that does it for them, just as they have to do with normal PHP files, or to bundle it all up in 1 phar. In other words, once you split a phar into multiple files, you've lost the primary benefit. Of course, we could move the discussion to pecl-dev if you'd like to talk about features in phar. I find it rather lame that your first response is "phar can't do this" when it is in alpha stage (meaning anything can be changed or added if needed) and has no releases... Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
