I'd say, "Go for it!" But on the other hand I wonder if it might make sense to have something more generic, so that one only has to call something in a way such as
virtualx_setup run_tests --foo virtualx_cleanup The reason why I'm wondering this is that we need some more "virtual environments" for testing purposes, really: so many packages need a D-Bus session (and I'd rather have them using a test session than a system one!), and at least in Ruby world we often need a database (sometimes more than one)... Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On Mon, Feb 11, 2013 at 11:14 PM, Michał Górny <mgo...@gentoo.org> wrote: > Hello, fellow developers, > > The current virtualx.eclass API is a bit insane. It seems a bit like > stacking of a few next APIs, mostly designed to quickly run 'make > check', then extended to general functions. > > For example running a function 'run_tests' with parameter '--foo' would > look like: > > VIRTUALX_COMMAND=run_tests virtualmake --foo > > which is really awful, considering that '--foo' is a parameter to > 'run_tests' and not virtualmake. > > My patches introduce a single wrapper with argv-as-parameter syntax. > That is, the fore-mentioned example would look like: > > virtualx run_tests --foo > > Depending on the maintainer decisions and your feedback, I believe that > even all the X* short-hand functions could be deprecated. They are a bit > shorter: > > Xemake check > > vs: > > virtualx emake check > > but I don't think that's much of a difference. > > What are your thoughts? > >
