[Avocado-devel] Implement fetch-assets command line

[Cleber Rosa]

On Thu, Sep 26, 2019 at 09:49:06AM +0200, Lukáš Doktor 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).

Hi Lukáš,

Rest assured Willian is pretty much on top of the use case that led
him to work on this (the pointers he gave later help with that).

We should question the technical merits and how some work fits into
the architecture (which you also did later here).  But trying to
manage anyone's time and effort, even if you think it's in project's
best interest, is out of place.

> 
> 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).
>

I can't see a way to separate what I think you call "cache-management
interface" work without considering that the assets we want to caches
are defined in tests.

> >> 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).

Behavior "by convention" is pretty much common in the software
industry, and I don't think it's seen as a bad practice.  Reserved
words (or file names) are also pretty common, and in fact Avocado
already does that in the "output check record" feature.

If you've followed the entire dicussion so far, you've probably
understood the pros and cons of the approaches discussed.  The
docstring and class variable with static analysis is limited to
static content and won't cut it for some types of tests.

> 
> 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="..."}}
>

Analyzing this example staticaly should be easy.  But if, say,
"location" is code that needs to be evaluated, it just won't work
without opening a major can of worms.

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

No, we want to have knowledge about the assets without executing
tests.  This won't work.

- Cleber.

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