[Distutils] developing & managing multiple packages with dependencies

[Antonio Cavallo]

>> ith a DVCS it makes sense to have multiple repositories (a repo for

> each package, er, I mean 'module distribution'), though we do have a
> centralized workflow with a central server containing all the repos.

There's nothing specific on the source code control tool: I assume
developers will rely anyway on a "frozen" module/package set (or release, or
tag or KGS as you named later on). 

> development and a release branch for each major + minor version
> number. For example maintenance version 2.7 would have the branches
> dev_2.7 and rel_2.7.

For the version (the one exposed through __version__) is it worth to keep
it as X.Y.Z or it may break the bdist_msi installer, especially if you're on
a multiplatform: I wished they standardised ___version__ to be this way in the
language so intra package dependency could be done in a reasonable way.

> Well, we're pretty much relying on setuptools/buildout, and I don't
> see anything wrong with that, as long as we have a reasonable
> migration path distribute/distutils2

In the past (it might be still now) it tried to replace python distribution files
(like site.py if I'm not wrong, it was long while ago): so at each python 
upgrade/patch released (like in security patches) you needed to reinstall it,
breaking dependencies. 

Beside the technical reasons, from a network administration point of view 
is a bad way to replace a native way to install things. Plenty of company 
have developers without administrator privileges on a machine.

All of a sudden if you are a syadmin and must  know what is installed 
on a remote machine (possible in another continent) you could not use 
any longer the standard system tools (rpm -qi on linux) but you need 
to be logged as the developer and go figuring out the way he/she 
installed things.

Again I suggest to stay away from anything that relies on setuptools, that
is my professional experience, and I haven't seen any (good) reason
to suggest the contrary: you needs might be different. 

> The actual release to the customer usually involves a selection of
> 'top level' packages, and all of them need to rely on the same version
> of the core library dependencies.

That is what I meant (KGS) at the begin of the message, I think I haven't expressed myself 
clearly :( If you use hudson (or anything like that) you should have a plan to not
hand fiddling with files anyway.

> 
>> For legal reason and traceability reasons anything that attempt to
>> download or "dinamically" do things is a no option.
> 
> I have no clue what you mean by that. What do you have against 'downloading'?

Traceability is I give you the "product" (in business lingo "deliverable") now the questions are:
 - What it depends upon? python + module foo version X + module bar version Y and so on.
 - How do I rebuild it if you company goes bankrupt (I hope not but it is an eventuality)?
 - Is there any hidden backdoor any of you employee has put in one of the many component?
 - How do we get the name of the offender if that happen?

Now you probably can see why I have a LOT against wild downloading. 
Beside this there are licensing problems like using GPL code on a commercial 
software although I must admit python is quite liberal on that point.


I hope this helps.
Best regards,
Antonio