Re: Conditional package dependencies?

From: Date: Fri, 08 Jun 2007 19:06:38 +0000
Subject: Re: Conditional package dependencies?
References: 1 2 3  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-46983@lists.php.net to get a copy of this message
Seems like the PHP4 / PHP5 barrier is significant enough to justify allowing separate dependency sections in package.xml, one for each "PHP generation", which can later be extended to include the PHP6 generation. Or, perhaps each dependency object itself could be allowed to have its "required vs. optional" dependency attribute work in tandem with a PHP Generation attribute, so that Mark could spec that his dependency X is optional for PHP4 but required for PHP5. However, thinking this out further, people would probably later want to expand it into PHP versions rather than generations, so the one or two barrier boundaries would grow significantly. If I had put this kind of construct in my code, to where I'm checking to see if a particular capability is available (PHP5) and fall back to something else if it's not (PHP4), then I'd probably choose to mark the PHP4 dependency as required (MUST be there for the fallback) and the PHP5 dependency as optional (HOPE it's there because I obviously like it better than what's in the fallback dependency). Then, it's up to me to put in the README/INSTALL that "if you have PHP5, you SHOULD choose to install optional dependency X to take advantage of better performance / handling-on-wet-curves-during-heavy-wind / whatever." I don't think I can talk myself into messing with the complexity of trying to bend the installer's dependency resolution into handling this scenario just for "ultimate flexibility" in what I want installed. It would be up to me, the one choosing to put such a construct in my code, to be responsible for working up an acceptable use of the capabilities of the dependency resolution mechanism at my disposal. I can see the benefits of coding things like this, trying to take advantage of the new/better things while also failsafing back to old/works things, but bending the installer to deal with such seems to me like it would make the dependency resolution logic an order of magnitude more complex, and therefore not a good tradeoff in the end. If my reply reads like a stream of thought as the thought progressed, it's because that's exactly what happened. I didn't start talking myself OUT of the idea until I'd nearly finished the first paragraph. -- CRB Let me introduce you to my very own DMCA-protected encryption key: BC 1B 64 4A 8D DE 49 E8 C3 7D CC EE 1A AD EE F5 (compliments of Freedom-to-Tinker http://www.freedom-to-tinker.com/?p=1155)

« previous php.pear.dev (#46983) next »