Bug#833407: Please put adt-virt-* binaries back onto PATH

[Johannes Schauer]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/autopkgtest-devel/attachments/20160812/a3b02328/attachment-0001.sig>