Project organisation
Imagine I have x projects and they all use util.py What would be the best way to organise this 1. c --\project1\*.py | |-\project2\*.py | --\globals\util.py This organisation has the problem that if I have to modify something to util.py that I need in project2, I'll have to retest project1 to make sure it still works (that could be project 1..n). 2. A copy of util.py in each project directory ? The advantage is that I can modify each util.py in function of the need of the project but it looks clutered, having n versions of util.py. What is the best solution ? or is there another even better solution ? Rony -- http://mail.python.org/mailman/listinfo/python-list
Re: Project organisation
rony steelandt wrote: Imagine I have x projects and they all use util.py What would be the best way to organise this 1. c --\project1\*.py | |-\project2\*.py | --\globals\util.py This organisation has the problem that if I have to modify something to util.py that I need in project2, I'll have to retest project1 to make sure it still works (that could be project 1..n). Of course it does. And if you genuinely want to share components between projects, how else could you verify that utility changes for one project hadn't broken the other? 2. A copy of util.py in each project directory ? The advantage is that I can modify each util.py in function of the need of the project but it looks clutered, having n versions of util.py. It will aslso give you probems if they get out of step, or if you want to make parallel changes in them all. I certainly wouldn't recommend this. What is the best solution ? or is there another even better solution ? Seems to me that the best solution of all would be to have independent tests for the functionality defined in utils.py, and to run those tests after each change no matter for which project. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden -- http://mail.python.org/mailman/listinfo/python-list
Re: Project organisation
rony steelandt wrote: Imagine I have x projects and they all use util.py What would be the best way to organise this 1. c --\project1\*.py | |-\project2\*.py | --\globals\util.py This organisation has the problem that if I have to modify something to util.py that I need in project2, I'll have to retest project1 to make sure it still works (that could be project 1..n). 2. A copy of util.py in each project directory ? The advantage is that I can modify each util.py in function of the need of the project but it looks clutered, having n versions of util.py. What is the best solution ? or is there another even better solution ? Extensive automated regression tests certainly helps! Take a look at e.g. http://www.texttest.org/ This is really not a Python issue at all, it would be the same thing with a util.dll written in C++... -- http://mail.python.org/mailman/listinfo/python-list
Re: Project organisation
On Wednesday 19 July 2006 3:12 pm, rony steelandt wrote: Imagine I have x projects and they all use util.py What would be the best way to organise this 1. c --\project1\*.py |-\project2\*.py --\globals\util.py This organisation has the problem that if I have to modify something to util.py that I need in project2, I'll have to retest project1 to make sure it still works (that could be project 1..n). 2. A copy of util.py in each project directory ? The advantage is that I can modify each util.py in function of the need of the project but it looks clutered, having n versions of util.py. What is the best solution ? or is there another even better solution ? You could introduce version numbers to your module hierarchy... --\globals\v1-0\util.py \v1-1\util.py \v2-0\utill.py ...then in your code do something like... from globals.v1-0 import util ...which would allow some sharing without needing to retest. Phil -- http://mail.python.org/mailman/listinfo/python-list
Re: Project organisation
rony steelandt [EMAIL PROTECTED] writes: Imagine I have x projects and they all use util.py What would be the best way to organise this 1. c --\project1\*.py | |-\project2\*.py | --\globals\util.py This organisation has the problem that if I have to modify something to util.py that I need in project2, I'll have to retest project1 to make sure it still works (that could be project 1..n). 2. A copy of util.py in each project directory ? The advantage is that I can modify each util.py in function of the need of the project but it looks clutered, having n versions of util.py. What is the best solution ? or is there another even better solution ? Rony Is util.py supposed to do the same thing wherever it is used? No one can answer that for you. Your comments suggested mostly the same, but some differences. In that is the case, then use one main util.py for the common items, and do a local util.py for the locally-specific items. Given proper attention to paths, there should be no confusion. I wouldn't bury the common util.py in a package called globals. That could get really confusing. You might make it a standalone package, or maybe use utilities or common. -- Harry George PLM Engineering Architecture -- http://mail.python.org/mailman/listinfo/python-list
Re: Project organisation
Le Wed, 19 Jul 2006 14:31:06 +0100, Phil Thompson a écrit : On Wednesday 19 July 2006 3:12 pm, rony steelandt wrote: Imagine I have x projects and they all use util.py What would be the best way to organise this 1. c --\project1\*.py |-\project2\*.py --\globals\util.py This organisation has the problem that if I have to modify something to util.py that I need in project2, I'll have to retest project1 to make sure it still works (that could be project 1..n). 2. A copy of util.py in each project directory ? The advantage is that I can modify each util.py in function of the need of the project but it looks clutered, having n versions of util.py. What is the best solution ? or is there another even better solution ? You could introduce version numbers to your module hierarchy... --\globals\v1-0\util.py \v1-1\util.py \v2-0\utill.py ...then in your code do something like... from globals.v1-0 import util ...which would allow some sharing without needing to retest. Phil Yes, this actually looks like a very good idea, without the need of retesting everything Rony -- http://mail.python.org/mailman/listinfo/python-list
Re: Project organisation
You could introduce version numbers to your module hierarchy... --\globals\v1-0\util.py \v1-1\util.py \v2-0\utill.py ...then in your code do something like... from globals.v1-0 import util ...which would allow some sharing without needing to retest. Or you use setuptools to create a utils-egg, that can easily be versioned and you can require a dependend package to require a certain version. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: Project organisation
If a particular project requires slightly different functionality from the classes in Utils.Py one way would be to import Utils.py and then either monkey-patch or subclass the classes you need to extend or modify for that project. That way you will have no effect whatever on the other projects. Simon Hibbs -- http://mail.python.org/mailman/listinfo/python-list
