>> 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 _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
