Re: organizing your scripts, with plenty of re-use
y probably don't even know they are running from a cvs repository. They in fact may think of it as their own personal installation, and all they know is that they have scripts directory and that that scripts directory has some scripts they want to run. As Buck said, it can often be very difficult to get things properly and quickly installed in a large corporate environment, and providing the user with a way to check out a cvs repository can be very quick and easy. The problem is that once the user has access to that cvs repository, it is difficult to tell them "hey, every time you run from it, you need to execute this special command to set up your PYTHONPATH environment variable." I don't really see any good solution to this other than some boilerplate code at the beginning of each script that overrides PYTHON_PATH. I think what I'd do in this situation is have a dot file that indicates that you are running out of a "dev" (ie cvs repository) area. Then some boilerplate code like this at the beginning of your scripts: if os.path.exists(os.path.dirname(sys.argv[0]) + "/.dev"): sys.path.append(os.path.abspath(os.path.dirname(sys.argv[0])) + "/..") This basically says "if the .dev file exists, put the parent directory of the script into sys.path." When an installation is done, as part of the install the .dev file should be removed. In that case the libraries should be installed into the standard site-packages location and the user running from an install would automatically get their packages from the installation area. While having boilerplate code like this at the beginning of the script is not great, I do think that it will save a lot of user questions/ confusion if the users are frequently running from one or more cvs repositories. For example, if requiring the user to explictly set PYTHONPATH, if the user has two cvs repositories, with different versions of the code, a user that is not very python-knowlegable will frequently forget to update their PYTHONPATH and will end up running new scripts with an old library. Having this boilerplate code should avoid a problem like that. So I think the pros probably outweigh the cons. Margie -- http://mail.python.org/mailman/listinfo/python-list
Cool new website
Brand new site. Loads of great stuff Free membership and full access Check out Yapooh! http://www.yapooh.org -- http://mail.python.org/mailman/listinfo/python-list
How to see intermediate fail results from unittest as tests are running?
Hi, I am using unittest in a fairly basic way, where I have a single file that simply defines a class that inherits from unittest.TestCase and then within that class I have a bunch of methods that start with "test". Within that file, at the bottom I have: if __name__ == "__main__": unittest.main() This works fine and it runs all of the testxx() methods in my file. As it runs it prints if the tests passed or failed, but if they fail, it does not print the details of the assert that made them fail. It collects this info up and prints it all at the end. Ok - my question: Is there any way to get unittest to print the details of the assert that made a test fail, as the tests are running? IE, after a test fails, I would like to see why, rather than waiting until all the tests are done. I've searched the doc and even looked at the code, and it seems the answer is no, but I'm just wondering if I'm missing something. Thanks! Margie -- http://mail.python.org/mailman/listinfo/python-list
Re: How to see intermediate fail results from unittest as tests are running?
On Aug 19, 12:41 am, Peter Otten <__pete...@web.de> wrote: > Margie Roginski wrote: > > I am using unittest in a fairly basic way, where I have a single file > > that simply defines a class that inherits from unittest.TestCase and > > then within that class I have a bunch of methods that start with > > "test". Within that file, at the bottom I have: > > > if __name__ == "__main__": > > unittest.main() > > > This works fine and it runs all of the testxx() methods in my file. > > As it runs it prints if the tests passed or failed, but if they fail, > > it does not print the details of the assert that made them fail. It > > collects this info up and prints it all at the end. > > > Ok - my question: Is there any way to get unittest to print the > > details of the assert that made a test fail, as the tests are > > running? IE, after a test fails, I would like to see why, rather than > > waiting until all the tests are done. > > Not exactly what you're asking for, but 2.7 has grown a --failfast option > that tells unittest to stop on the first failure. For older Python versions > you can use nose > > nosetests -x myscript.py > > athttp://somethingaboutorange.com/mrl/projects/nose/0.11.2/ > or the unittest backport athttp://pypi.python.org/pypi/unittest2 > > Peter Thanks for the pointers, I will give those a try. Margie -- http://mail.python.org/mailman/listinfo/python-list
