Re: [DISCUSSION] python version requirement

[Ondrej Lichtner]

On Mon, Jul 06, 2020 at 03:29:02PM -0400, Perry Gagne wrote:
>  Hey I agree we should standardize on a version of python. I would
> think 3.8
>  would be the best.
>  
>  Just one thing to note, F-strings are actually a python 3.6 feature, so
>  that shouldn't be something we need to worry about here. 
Hm, I do remember you asking about some feature that wasn't in 3.6
though, didn't I? Maybe I'm just confusing f-strings for something
else...

>  
>  --Perry
>  
>  On Fri, Jul 3, 2020 at 4:39 AM Ondrej Lichtner <olichtne(a)redhat.com&gt; wrote:
>  
>  > Hi all,
>  >
>  > since we've moved to python3 that is actively developed and versions
>  > move between various long term/short term support cycles, we should also
>  > adapt LNST to this cycle of updating which minimal version of python
>  > LNST requires.
>  >
>  > TL;DR: The main questions I'm asking are:
>  > * how do we _implement_ a python version requirement?
>  > * how do we _upgrade_/_migrate_ in the future?
>  > * how do we _document_ a python version requirement?
>  > * which version do we want to use _now_?
>  >
>  > More context:
>  >
>  > I think at the moment we have a "soft" requirement for python3.6. Soft
>  > because we:
>  > * probably haven't tested on anything older
>  > * it's not explicitly configured/documented anywhere
>  >
>  > At the same time, there are now at least two reasons to start thinking
>  > about moving to python3.8:
>  >
>  > * I remember Perry asking about the f-string feature introduced in 3.8
>  > * while working with Adrian on the TRex refactoring I started thinking
>  >   about a feature for the lnst.Tests package that I've had in mind for a
>  >   while, which requires a 3.7 feature
>  > * python3.8 is the current version on Fedora32, is available in RHEL8
>  >   (via dnf install python38), and python3.7 was skipped
>  >
>  > The lnst.Tests feature I'm thinking of is "lazy" and
> "dynamic" loading
>  > of BaseTestModule derived modules - for example at the moment, if a
>  > Recipe imports any module from lnst.Tests (e.g. lnst.Tests.Ping), the
>  > entire package is parsed and "loaded", which means that the python
>  > environment will also parse and load lnst.Tests.TRex. This means that a
>  > basic hello world recipe that simply calls Ping, will in some way
>  > require load time dependencies of TRex.
>  >
>  > The "lazy" and "dynamic" loading of test modules would ensure
> that when
>  > a recipe calls:
>  >
>  >     from lnst.Tests import Ping
>  >
>  > Only the Ping module will be parsed, loaded and imported, and nothing
>  > else. And the dynamicity here could mean that we could be able to extend
>  > test modules exported by the lnst.Tests package via the lnst-ctl config
>  > file, for example for user/tester implemented test modules that are not
>  > tracked in the main lnst repository.
>  >
>  > I wrote a rough patch to experiment with this:
>  >
>  > ---
>  > diff --git a/lnst/Tests/__init__.py b/lnst/Tests/__init__.py
>  > index f7c6c90..a39b6f4 100644
>  > --- a/lnst/Tests/__init__.py
>  > +++ b/lnst/Tests/__init__.py
>  > @@ -12,8 +12,26 @@
>  >  olichtne(a)redhat.com (Ondrej Lichtner)
>  >   """
>  >
>  >    -from lnst.Tests.Ping import Ping
>  >    -from lnst.Tests.PacketAssert import PacketAssert
>  >    -from lnst.Tests.Iperf import IperfClient, IperfServer
>  >    +# from lnst.Tests.Ping import Ping
>  >    +# from lnst.Tests.PacketAssert import PacketAssert
>  >    +# from lnst.Tests.Iperf import IperfClient, IperfServer
>  >    +import importlib
>  >    +
>  >    +lazy_load_modules = {
>  >    +    "Ping": "lnst.Tests.Ping",
>  >    +    "PacketAssert": "lnst.Tests.PacketAssert",
>  >    +    "IperfClient": "lnst.Tests.Iperf",
>  >    +    "IperfServer": "lnst.Tests.Iperf",
>  >    +}
>  >    +
>  >    +
>  >    +def __getattr__(name):
>  >    +    if name not in lazy_load_modules:
>  >    +        raise ImportError("Cannot import {}".format(name))
>  >    +    mod = importlib.import_module(lazy_load_modules[name])
>  >    +    globals()[name] = getattr(mod, name)
>  >    +    return globals()[name]
>  >    +
>  >    +
>  >    +# #TODO add support for test classes from lnst-ctl.conf
>  >
>  >     -#TODO add support for test classes from lnst-ctl.conf
>  > ---
>  >
>  > However this requires the ability to define __getattr__ for a module,
>  > which is introduced as a python3.7 feature via PEP562 [0].
>  >
>  > -Ondrej
>  >
>  > [0] https://www.python.org/dev/peps/pep-0562/
>  > _______________________________________________
>  > LNST-developers mailing list -- lnst-developers(a)lists.fedorahosted.org
>  > To unsubscribe send an email to
>  > lnst-developers-leave(a)lists.fedorahosted.org
>  > Fedora Code of Conduct:
>  > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  > List Archives:
>  > https://lists.fedorahosted.org/archives/list/[e-mail]...
>  >