On Wed, Mar 04, 2009 at 05:55:02PM -0800, Marek Szuba wrote: -> On Wed, 4 Mar 2009 12:22:09 -0800 -> "C. Titus Brown" <[email protected]> wrote: -> -> > If you use runtest -b it will look in the build directory instead. -> I talked to Chris shortly after sending the previous message -> and he also mentioned the -b flag, which indeed solves the problem. -> However, I think we should make using the build directory the default -> rather than a selectable option. Why? Let us not forget it isn't just -> developers who run tests - sometimes an ordinary user may want to do -> this as well to verify his installation went fine, which is especially -> pertinent to third-party, non-distribution packages and/or ones which -> come with a test suite rather than offering it separately; Pygr in -> its present form meets both of these criteria. Now, imagine you're such -> a user and, after installing Pygr in accordance with instructions from -> the README, you run 'python runtest.py' (also in accordance with the -> README, albeit a different one) - only to get a cryptic message about -> being unable to load the cnestedlist module... -> -> It is my strong belief that if we are indeed to make 0.8 more -> user-friendly, this needs to be changed.
I think I was the first person to really mess with this in protest.py, even though Istvan has continued the tradition ;). So I've had plenty of time to think about it... If runtest runs pygr out of the development directory by default, then the tests will run against your latest source code changes to Python files. (You'll still have to compile .pyx and .c files yourself, of course.) However, if runtest runs pygr out of the build directory by default, you run the risk of running new tests against a stale build. This is not obvious when it happens, and can lead to frustrating (and largely invisible) errors. I don't think there's a solid way of resolving this -- - originally, protest ran the tests out of the build directory, and I got bitten by this behavior; - then I changed it to look first in the dev and then in the build directory, and Chris complained because that was causing problems; - Istvan wrote runtest to run pygr out of one place, specified on the command-line and defaulting to the dev directory; - Marek now wants to go back to running the tests out of the build directory in order to be user-friendly. ...and I think we can continue arguing indefinitely ;) So it's a judgement call and someone just needs to decide what the default behavior will be, IMO. As long as it's possible to specify where the test code looks for pygr in some fire-and-forget way (by setting an environment variable, for example) it won't affect me; I can simply set it once and fuggedaboudit. However, I think Istvan's approach of keeping the current behavior BUT producing an informative (user-oriented) error message is an equally reasonable way to go in order to be user-friendly. cheers, --t -- C. Titus Brown, [email protected] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pygr-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/pygr-dev?hl=en -~----------~----~----~----~------~----~------~--~---
