# jochem@xxxxxxxxxxxxx / 2007-01-16 11:41:08 +0100: > Roman Neuhauser wrote: > > # jochem@xxxxxxxxxxxxx / 2007-01-14 20:47:02 +0100: > >> Roman Neuhauser wrote: > > The goal is to make a successful run of the test suite a prerequisite of > > the utility installation... Think RPM or similar: if X.rpm depends on > > Y.rpm in runtime, you cannot make Y's installation depend on execution > > of commands from X. > > ok, I'm not grokking this fully - I'll just have to take you word on it :-) 1. testilence.rpm requires (installed) testilence-util.rpm to install since testilence uses testilence-util at runtime, and 2. testilence-util.rpm requires (installed) testilence.rpm before it will install, because it runs commands (installed by testilence.rpm) as part of its install procedure > >> ... whilst I wonder whether using runkit for anything other than experimental > >> stuff, could runkit not offer a solution (e.g. renaming the class dependent on > >> the context of it's usage)? probably not, right? > > > > How would this work? > > from looking at runkit it would seem using runkit_import() would work, > it would mean you simply 'include' the utility class(es) in both Testilence and > Amock using runkit_import() and that would simply cause the second 'include' > to overwrite the class definition of the first include. That is evil. You have installed Testilence, it works. You install Amock, Testilence broke. Reason: incompatible versions of the utility. I know that whatever solution I end with will affect all clients of the classes (Amock, Testilence, 3rd party sw), what I'm looking for is something that will be easy to express and support using deployed packaging systems (*BSD ports, pkgsrc, RPM, whatever Debian uses ATM). > this could also be tackled using a chain of __autoload() functions. How could you use Testilence to test your __autoload() if Testilence already used it? How could you test anything that depends on __autoload() if Testilence used that mechanism? What would preserve the mechanism if the CUT used a naive __autoload()? FMPOV __autoload() is untouchable and shouldn't be used at all. > either way having a runtime dependency in your code is probably not a > good idea even for a develop-time tool like yours is (because it's > marked experimental and it raises the bar as to the getting your tool > working) If you can install Testilence you can probably also extract a tarball into a directory in your include_path. :) > >>> Both Amock and Testilence are versioned using Subversion, so I could > >>> leave the classes in Testilence and use svn:externals to put them in > >>> Amock too. That would lead to name clashes if both programs were used > >>> together, and that is a showstopper. > >> given that they are the same code would conditional loading of the utlity > >> classes not work? i.e. only load if they don't already exist > > > > That seems quite fragile, but I admit I haven't thought it through. > > unless the class is called something silly like 'Foo' or 'Utility' > then I think that in practice the problem is negligable. Still the objection I gave above: seemingly independent programs would silently influence each other's behavior. I'd rather make this relationship visible through the explicit dependency. > > So far I'm leaning towards pulling the utility out from Testilence, > > sacrificing the ability to unit test the library without jumping through > > hoops. > > that seems sane - hopefully the utility won't change half as often as > the 'real' tools and given that you test the utility yourself before packaging > you know that it works ... maybe including your test results in the utility > package is something to consider? I'd include the tests of course. The steps would then be: install utility + its tests: no tests are run install Testilence + its tests: both utility's and Testilence's tests are run before anything is installed For other users of the utility, such as Amock: see above, plus: install Amock + its tests: both utility's and Amock's tests are run before anything is installed -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
