[Avocado-devel] Implement fetch-assets command line

[Amador Pahim]

On Thu, Sep 26, 2019 at 9:49 AM Lukáš Doktor <ldoktor at redhat.com> wrote:
>
> Hello guys,
>
> what a nice discussion. But before you start, what lead you to pick this card? It's one of the nice-to-have-ideas card and we have plenty of well-defined-and-useful cards that also needs attention, so unless you have a real-world usage, I'd probably suggest to focus on something you can directly benefit from. (unless you have other interest in eg. learning something, or other kind of interest).

Fair point. A RFC would do some good here.

>
> Dne 25. 09. 19 v 23:39 Cleber Rosa napsal(a):
> > On Wed, Sep 25, 2019 at 06:01:22PM -0300, Willian Rampazzo wrote:
> >> After going thru the suggestions, and thinking about it, I came up
> >> with the following starting point:
> >>
> >> 1 - Support a limited test source code parsing. This feature brings a
> >> simple solution to those tests already using strings into their
> >> fetch_asset parameters, as stated by Cleber.
> >>
> >
> > Keep in mind that I'm assuming this is a viable option without
> > attempting to do it myself.  I hope it's viable, because it makes
> > "simple things easy" from the test writer's side.
> >
>
> Yes, this makes sense to me and would be useful even for some human-asset interface (list assets, list cached assets, see details of cached assets...). Btw cache-management interface is IMO higher in the priority than actually fetching the assets without executing tests (but it's just my priority list, don't take this as an official statement).
>
> >> 2 - Add an option to use assets.json, as stated by Amador. This file
> >> would sit in the test data folder and list all assets that are
> >> necessary for the test. As a list of assets, I thought about a new
> >> method, fetch_assets, as a wrapper that load all assets from the file
> >> and call fetch_asset for each one.
> >>
> >
> > Sounds good.  Also consider the need for dynamic asset definition (the
> > idea about executable scripts that produces JSON).
> >
>
> Hmm, this is tricky. I don't like much having "reserved" file names as people might get unwanted clashes. Yes, it should be fairly harmless with a json file (either it matches or is skipped) but it's a semi-hidden feature. We also have the https://trello.com/c/WPd4FrIy/1479-add-support-to-specify-assets-in-test-docstring that sounds more explicit to me. Another alternative I'd prefer is a `Test` class variable, which can be obtained by a static analysis, or even `Test` variable initialized on `__init__`, which could be executed by the asset fetcher interface (when asked for, because it might eventually execute some nasty code). Having a pre-defined file names in datadir locations is the last interface I'd like to see in Avocado (out of these).
>

I don't think reserved filenames are a good way either. The baseline
from my suggestion is an external file containing the arguments that
will be used by both the asset.Asset(from_file=filename.json) and by
the command line tool that will cache things: avocado fetch-asset
filename.json filename2.json filename3.json.


> As before, if you have some real-world use case, please share it as it can change everything.
>
>
> class variable
> --------------
>
>     class MyTest(avocado.test):
>         assets = {"foo": ["http://aaa"], "bar": {"location": "http://fdsa", hash="..."}}

This seems like a good alternative, but it also seems like one more
source or parametrization. I'd then use the parametrization interface
instead.

>
> initialized variable
> --------------------
>
>     class MyTest(avocado.test):
>         def __init__(self, ...):
>             self.assets = {}
>             for asset in something:
>                  self.assets[asset] = get_asset_url(asset)

I would not ask users to deal with __init__ in their test classes.

>
> ---
>
> Regards,
> Lukáš
>


-- 
Pahim