Bug#833407: Please put adt-virt-* binaries back onto PATH
Johannes Schauer [2016-08-12 9:11 +0200]:
> Are you suggesting that every consumer of the virt backends embeds Python code
> to do that?
I'm suggesting that using the Python API is much easier, *if* your
program is already written in Python or can embed Python easily . If
this is not the case, then it's of course fine to use the virt backend
> > 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.
I am okay with adding another lookup path: I. e. a virt backend xxx is
searched in /usr/share/autopkgtest/virt/xxx and /usr/bin/[some prefix]-xxx
unless it is specified with full path.
But this is moot as long as there aren't actually any external
or compiled backends.
> And again we have not solved the problem that everybody is implementing their
> own wrapper to vitalization environments.
TBH, I don't consider the autopkgtest virt backends as a generic,
useful, and comfortable API for that -- it would need a lot of design
work, libraries etc. to become that. For most projects it would be
simpler to use schroot or lxc-attach directly rather than re-writing
all the encoding, pipelining, and timeout stuff for autopkgest's virt
backends, and for most projects it does not make that much sense to
offer the full choice of supported backends. But of course YMMV and I
don't want to stop people from reusing these :-)
 By depending on autopkgtest you already transitively depend on
python3, so this is not a question of extra dependencies.
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: not available