With the introduction of VMDIRAC and LHCbVMDIRAC we are facing the decision on how to make a package that includes extension. Up to now, we always had one extension (Web) but we never really needed to include it in some package so that we could do "from Web import ...". With (LHCb)VMDIRAC, and with all the future extensions that we might want to use, we'd need a way to do something like: > SetupProject aLHCbProject vXrY --> (this name is definitely subject to discussion) > python >>> from DIRAC import * --> this we have >>> from LHCbDIRAC import * --> this we have >>> from VMDIRAC import * --> this we don't have >>> from LHCbVMDIRAC import * --> this we don't have and so on. Right now, each LHCbDIRAC depends from (in CMT): - DIRAC - LHCBGRID while LHCbVMDIRAC depends from: - VMDIRAC - LHCbDIRAC This isn't the best, because: - to work on LHCbVMDIRAC code you need to do "SetupProject LHCbVMDIRAC". And with the new contextualization (so, with the pilots to come) it isn't feasible. - the day we'll introduce a new package (e.g. COMDIRAC) we'll need to add a new layer of dependencies In everything we've done up to now, there's an overlapping between the project name (LHCbDIRAC) and the code name (LHCbDIRAC). Instead, the project LHCbDIRAC should use the code of LHCbDIRAC in the same way as it use the code of, e.g., LHCbVMDIRAC. So, my suggestion is to have another project (the one that before I called "aLHCbProject") that includes all the code packages that we need. My suggestion is to call it either BeautyDirac or LbDirac (please shoot!). This would include, in CMT: - DIRAC - VMDIRAC - LHCbDIRAC - LHCbVMDIRAC - LHCBGRID Then, it can also include the Web, I don't really mind. I propose to start applying this packaging directly from when LHCbDIRAC (the code, not the project!) will be tagged as v7r15, so we would have something like the following project.cmt: project BeautyDirac use DIRAC DIRAC_v6r10 use VMDIRAC VMDIRAC_v0r8 use LHCbDirac LHCbDirac_v7r15 use LHCbVMDirac LHCbVMDirac_v0r1 use LHCBGRID LHCBGRID_v5r* use LCGCMT LCGCMT_64d build_strategy with_installarea setup_strategy root structure_strategy without_version_directory container LHCbDiracSys We would than have a new release of the BeautyDirac project every time there is a new tag on any of the included packages. The version of the BeautyDirac project can even start from v0r1. In any case, it should by no means be bound to any of the tags of the single packages: so NO start from BeautyDirac v7r15! -------------------------------- Comments -------------------------------- Mario --------------- I'd redo the way we tag LHCbDIRAC ( code ) in the sense that we could simply create a tag of LHCbDIRAC from the branch_vXrY which will become LHCbDIRAC_vXrYpZ without all the nuisance of having to tag each and every single module. Regarding the name, BeautyDirac seems reasonable to me. Now, question from my ignorance. Why do we need to use CMT et al to release a purely Python project ?