Re: (Fwd) [PEAR] RE: [PEAR-DEV] dependencies and applications

There is no way you can modify the structure like this generally.. - things like factory methods break badly if you mess around with the path..(or filenames) - the solution is generally worse than the problem. the only way to make any of this work (as far as I can see) is to use set_include_path() in the application and add a application specific folder.. (and a application installer that understands targets on it's dependancies).. Regards Alan Stefan Neufeind wrote:

On 21 Aug 2003 at 16:03, Jan Schneider wrote:

Zitat von Stefan Neufeind <stefan@neufeind.net>:

As mentioned earlier (but to put it a bit different): Maybe having pear/MDB/MDB.php for all 1.x-releases and from PEAR 1.3 on also have pear/MDB/1.0/MDB.php is fine. From PEAR 2.0 on we can issue the warning as outlined before it still pear/MDB/MDB.php is used. And from 2.5 or so we should finally abandone these warning- files as well. From 1.3 to 2.0 there would be enough time for every package and every programmer out there to update his programs to work without any warnings. And when 2.0 comes out there is still some time until 2.5 finally breaks BC completely. What's so bad about such a solution?

Why not keep the current directory structure for all packages that already are released and switch to a new Package/VersionNumber/Package.php only for yet to be released packages or new major versions. This way you won't break BC even if in three year you still have an application from now depending on a package 1.0 while there is already PEAR 3.5 and package 4.1 out. If you depend on a new major version / new package in your application, you will use the new structure. No transition, no bc breakage, no version conflicts.

Another good idea, yes. But does this include that we encourage all maintainers to release a new major release that follows the new structure? I think that the packages itself should care about if they are installed in MDB/... or pear/MDB/2.0/... This could be handled by the installer. And I think it's possible to make the transition "smooth" (as stated in my previous mail). Meanwhile we could check if packages internally use relative or absolute paths for dependencies / includes and suggest to the maintainers to upgrade their packages. I'd volunteer to check packages and mail the maintainers. Stefan

-- Can you help out? Need Consulting Services or Know of a Job? http://www.akbkhome.com