On Tue, Feb 12, 2013 at 01:58:01AM +0100, Ewoud Kohl van Wijngaarden wrote: > On Mon, Feb 11, 2013 at 12:17:39PM -0500, Federico Simoncelli wrote: > > It is some time now that we are discussing an eventual repository > > reorganization for vdsm. In fact I'm sure that we all experienced > > at least once the discomfort of having several modules scattered > > around the tree. > > The main goal of the reorganization would be to place the modules > > in their proper location so that they can be used (imported) without > > any special change (or hack) even when the code is executed inside > > the development repository (e.g. tests). > > > > Recently there has been an initial proposal about moving some of > > these modules: > > > > http://gerrit.ovirt.org/#/c/11858/ > > > > That spawned an interesting discussion that must involve the entire > > community; in fact before starting any work we should try to converge > > on a decision for the final repository structure in order to minimize > > the discomfort for the contributors that will be forced to rebase > > their pending gerrit patches. Even if the full reorganization won't > > happen in a short time I think we should plan the entire structure > > now and then eventually move only few relevant modules to their final > > location. > > > > To start the discussion I'm attaching here a sketch of the vdsm > > repository structure that I envision: > > > > . > > |-- client > > | |-- [...] > > | `-- vdsClient.py > > |-- common > > | |-- [...] > > | |-- betterPopen > > | | `-- [...] > > | `-- vdsm > > | |-- [...] > > | `-- config.py > > |-- contrib > > | |-- [...] > > | |-- nfs-check.py > > | `-- sos > > |-- daemon > > | |-- [...] > > | |-- supervdsm.py > > | `-- vdsmd > > `-- tool > > |-- [...] > > `-- vdsm-tool > > Wondering if common should be named lib since you'll most likely want to > install it to the python lib dir anyway. Minor bikeshedding. > > Why the distinction between client and tool? Do you expect other scripts > to be added and give them all their own directory? I'd expect that most > of their code would mostly live in vdsm and the actual executables are > thin wrappers. This would match up with the scripts dir distutils has.
vdsm-tool is to be shipped with the server only. It is a tool that helps the admin (and the sysv/systemd service) configure the host for vdsm. It's code is part of common (or lib) only to make it easier to use it with the default sys.path. > > Where do the hooks go? They, too, are part of the daemon, but I think they can stay as a top-level directory as they are now. > > > This would allow any component (daemon, client, tool, etc...) to run > > in place with the only addition of PYTHONPATH=$(top_srcdir)/common. > > The tests would need also the additional component path but that is > > a given since it's what they should be testing. > > +1 on fewer hacks to load the environment. > > > Once the components are in the proper place we can eventually start > > using distutils inside the Makefile.am files in order to simplify the > > installation process (and also as verification that our repository > > structure is complying with the python standards). > > +1 IMHO use of auto* should be minimized when developing python. > _______________________________________________ > vdsm-devel mailing list > vdsm-devel@lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
