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