Project organisation

[Harry George]

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".

 

[Steve Holden]

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

 

[Magnus Lycka]

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++...

 

[Phil Thompson]

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

 

[rony steelandt]

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

 

[Diez B. Roggisch]

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

 

[Simon Hibbs]

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

 

[rony steelandt]

Le Wed, 19 Jul 2006 14:31:06 +0100, Phil Thompson a écrit :

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