refactor session

[gaborbernat]

While looking into doing #998 I realized the concept of env logs and actions have been heavily overlooked, furthermore the reporting should not be tied to the session (as we should report before the session object is constructed). This PR tries to fix all this and split up the longer and longer getting session.py.

[obestwalter]

Wow, that's a big one :)

Would you like feedback already about the direction this goes in? I'll have some time tomorrow afternoon to have closer look, if it makes sense already.

[gaborbernat]

@obestwalter yeah hence opening it 👍 even though not 100% ready yet.

[asottile]

I didn't get a chance to read through it all -- got about halfway through and realized github probably doesn't show moves well so I'll probably need to look using the cli

Overall the parts I looked at seemed fine, moving the reporter to a global seems risky, especially now that we;re doing parallel things

[asottile]

interesting, I've never seen this before -- I assume it just re-initializes the object? is this well defined?

[gaborbernat]

It's just a function call AFAIK 👍

[asottile]

seems well defined but ill-advised

[obestwalter]

I don't quite get, why this change is necessary at all.

[gaborbernat]

because we want to reset the report, calculated session venvs when a new config is loaded 👍 can use the _reset path though.

[obestwalter]

I only had time to skim through, but I like the general direction of it. I'll try to carve out some more time tomorrow to play with it.

[obestwalter]

I'd say let's run with this after the comments are addressed and test failures are fixed.

Stripping down the several __init__.py modules to what really hast to be there can be also done in a later PR.

Main thing is we keep backwards compatibility regarding the main objects that people use from other tools / plugins.

[gaborbernat]

This looks OK for now. I'm not 100% settled on the reporting thing, but we can take it for a test drive. Maybe instead we should just use the logging framework which we kinda mimic. But this can be a subsequent PR to migrate to that.

[cjerdonek]

It looks like this PR causes pip's CI to fail. Here is the traceback:

  File "/home/travis/virtualenv/python3.6.7/bin/tox", line 11, in <module>
    sys.exit(cmdline())
  File "/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/tox/session/__init__.py", line 42, in cmdline
    main(args)
  File "/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/tox/session/__init__.py", line 63, in main
    retcode = session.runcommand()
  File "/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/tox/session/__init__.py", line 187, in runcommand
    return self.subcommand_test()
  File "/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/tox/session/__init__.py", line 215, in subcommand_test
    run_sequential(self.config, self.venv_dict)
  File "/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/tox/session/commands/run/sequential.py", line 9, in run_sequential
    if venv.setupenv():
  File "/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/tox/venv.py", line 582, in setupenv
    status = self.update(action=action)
  File "/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/tox/venv.py", line 240, in update
    self.hook.tox_testenv_create(action=action, venv=self)
  File "/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/pluggy/hooks.py", line 284, in __call__
    return self._hookexec(self, self.get_hookimpls(), kwargs)
  File "/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/pluggy/manager.py", line 67, in _hookexec
    return self._inner_hookexec(hook, methods, kwargs)
  File "/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/pluggy/manager.py", line 61, in <lambda>
    firstresult=hook.spec.opts.get("firstresult") if hook.spec else False,
  File "/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/pluggy/callers.py", line 208, in _multicall
    return outcome.get_result()
  File "/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/pluggy/callers.py", line 80, in get_result
    raise ex[1].with_traceback(ex[2])
  File "/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/pluggy/callers.py", line 187, in _multicall
    res = hook_impl.function(*args)
  File "/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/tox_venv/hooks.py", line 99, in tox_testenv_create
    venv.session.make_emptydir(venv.path)
AttributeError: 'VirtualEnv' object has no attribute 'session'

Apparently this is because tox-venv relies on the VirtualEnv object's session attribute, which this PR removes: https://github.com/tox-dev/tox-venv/blob/31b874292ed3da5fee701d2a048db4c8b1ad8cae/src/tox_venv/hooks.py#L99

[cjerdonek]

Also, tox-venv's setup.py says:

install_requires=['tox>=2.0'],