Hi Martin, Quoting Martin Pitt (2016-08-12 08:42:02) > As for third-party users of the backends: Using the Python API > (adt_testbed.py) is a lot easier and more robust than talking to the > backend servers directly, due to all the encoding/decoding, timeout > handling, environment passing etc. -- if the goal is to avoid code > duplication, then using the virt backends directly only goes half way. > I don't actually want to promote and recommend using virt/* directly > for these reasons.
I may misunderstand you, but after having read your reply to the sbuild bug #833436 I have to ask: Are you suggesting that every consumer of the virt backends embeds Python code to do that? This is relatively painless for sbuild as it's written in Perl and embedding some Python code will be ugly and inconvenient but doable. But doing so is even less convenient in other programming languages. I thought that exposing this functionality via call-able programs with which one can interface via stdin/stdout was especially brilliant because it didn't impose any restrictions on the programming language that consumers of this functionality use. Any programming language can fork/exec and read from and write to file handles. > > Otherwise the out-of-tree server has to go in /usr/share/autopkgtest/virt, > > which is not really its bailiwick. (And what if the virt server is a > > compiled machine executable and unsuitable for /usr/share?) > > Both of these are only theoretical. Also, note that > /usr/share/autopkgtest/virt/ is only the default path, you can always > specify the full path to a virt server with autopkgtest(1). Sure you can, but that makes any virt server that is for its choice of programming language unsuitable for /usr/share somewhat "special". I do not see why the programming language should matter for the consumer. By making this move, you are artificially limiting adoption of this useful interface that earlier autopkgtest releases offered. If people see drawbacks of the current solution this might happen: https://imgs.xkcd.com/comics/standards.png And again we have not solved the problem that everybody is implementing their own wrapper to vitalization environments. Thanks! cheers, josch
signature.asc
Description: signature