Re: Conditional package dependencies?
| From: | Chuck Burgess | 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)