Project organisation

[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.p y

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

[Steve Holden]

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.p y
>
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

[Magnus Lycka]

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.p y
>
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]

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.p y
>
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

[Harry George]

Re: Project organisation

rony steelandt <bucodi@yahoo.f rwrites:

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.p y
>
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

[rony steelandt]

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.p y
>>
>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

[Diez B. Roggisch]

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

[Simon Hibbs]

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