1 |
I'd say, "Go for it!" |
2 |
|
3 |
But on the other hand I wonder if it might make sense to have |
4 |
something more generic, so that one only has to call something in a |
5 |
way such as |
6 |
|
7 |
virtualx_setup |
8 |
run_tests --foo |
9 |
virtualx_cleanup |
10 |
|
11 |
The reason why I'm wondering this is that we need some more "virtual |
12 |
environments" for testing purposes, really: so many packages need a |
13 |
D-Bus session (and I'd rather have them using a test session than a |
14 |
system one!), and at least in Ruby world we often need a database |
15 |
(sometimes more than one)... |
16 |
Diego Elio Pettenò — Flameeyes |
17 |
flameeyes@×××××××××.eu — http://blog.flameeyes.eu/ |
18 |
|
19 |
|
20 |
On Mon, Feb 11, 2013 at 11:14 PM, Michał Górny <mgorny@g.o> wrote: |
21 |
> Hello, fellow developers, |
22 |
> |
23 |
> The current virtualx.eclass API is a bit insane. It seems a bit like |
24 |
> stacking of a few next APIs, mostly designed to quickly run 'make |
25 |
> check', then extended to general functions. |
26 |
> |
27 |
> For example running a function 'run_tests' with parameter '--foo' would |
28 |
> look like: |
29 |
> |
30 |
> VIRTUALX_COMMAND=run_tests virtualmake --foo |
31 |
> |
32 |
> which is really awful, considering that '--foo' is a parameter to |
33 |
> 'run_tests' and not virtualmake. |
34 |
> |
35 |
> My patches introduce a single wrapper with argv-as-parameter syntax. |
36 |
> That is, the fore-mentioned example would look like: |
37 |
> |
38 |
> virtualx run_tests --foo |
39 |
> |
40 |
> Depending on the maintainer decisions and your feedback, I believe that |
41 |
> even all the X* short-hand functions could be deprecated. They are a bit |
42 |
> shorter: |
43 |
> |
44 |
> Xemake check |
45 |
> |
46 |
> vs: |
47 |
> |
48 |
> virtualx emake check |
49 |
> |
50 |
> but I don't think that's much of a difference. |
51 |
> |
52 |
> What are your thoughts? |
53 |
> |
54 |
> |