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