By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,544 Members | 1,460 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,544 IT Pros & Developers. It's quick & easy.

Project organisation

P: n/a
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

Jul 19 '06 #1
Share this Question
Share on Google+
7 Replies


P: n/a
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

Jul 19 '06 #2

P: n/a
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++...
Jul 19 '06 #3

P: n/a
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
Jul 19 '06 #4

P: n/a
rony steelandt <bu****@yahoo.frwrites:
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
Jul 19 '06 #5

P: n/a
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
Jul 19 '06 #6

P: n/a
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
Jul 19 '06 #7

P: n/a
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

Jul 19 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.