On 6 October 2012 00:02, holger krekel <hol...@merlinux.eu> wrote: > Hi Floris, > > On Fri, Oct 05, 2012 at 23:42 +0100, Floris Bruynooghe wrote: >> Hi Holger, >> >> One nice feature of the funcarg/setup merge into fixture is that you >> can now return a value from an autoactive fixture and request it >> anywhere else. I didn't think of this before but this is surprisingly >> useful as it provides a great alternative to storing things on e.g. >> session or item objects. > > Yes, i think so too. > >> However one issue I discovered is that is possible for a user to >> accidentally override an autoactive fixture. If you create a fixture >> with an identical name to the autoactive one it will be lost. I think >> this can be problematical for plugins. > > Hum, indeed, we have a global namespace for fixtures and unintentionally > shadowing plugin from project specific fixtures is easy. > >> What do you think the correct behaviour should be? I realise changing >> this could be hard/ugly. > > Not sure it's hard. first we need an idea what to do :) > > Hum. We could error out on the definition of fixtures if they already exist - > unless a flag aka "i know what i am doing" (e.g. override=True) is supplied.
That would not be as nice in the normal case. I do tend to extend funcargs quite a lot in my test suites. Although I guess it's not a horrible thing, it would have to default to override=True when using the backwards compatible pytest_funcarg__ syntax which then kind of defeats the point. Or are you proposing to only need this for overriding autoactive fixtures? _______________________________________________ py-dev mailing list py-dev@codespeak.net http://codespeak.net/mailman/listinfo/py-dev