Fix for "module 'enum' has no attribute 'IntFlag'" error when using python 3 for pack virtual environments under RHEL / CentOS

[Kami]

This pull request includes a fix for the AttributeError: module 'enum' has no attribute 'IntFlag' error which would appear when using python3 for a pack virtualenv (pack was created using use_python3=true parameter) and running on RHEL / CentOS (see https://forum.stackstorm.com/t/unable-to-run-an-action-implemented-by-python3/217/7 for details).

The issue was related to enum Python package being installed in python2.7 virtual environment. The python runner action script would try to use that package instead of enum module from Python 3 stdlib.

The fix includes adding <virtualenv path>/lib/python3.6 directory to PYTHONPATH for Python runner actions. This way we ensure Python 3 stdlib imports always have precedence over other python2.7 site-packages imports.

[blag]

Please consider adding some comments in the code about how this situation happens to begin with, not just what the fix is itself. I'm not 100% sure why you are fixing this the way you are, so if I'm 100% off base with the rest of my review, please disregard.

Okay, so the enum library is getting loaded from someplace it shouldn't be. Sounds like it's getting loaded from the system's Python environment. Is that correct? In that case, wouldn't a better fix be to create the pack's virtualenv with the --no-site-packages flag? That's been the default flag for virtualenv for quite some time now.

Or if the pack's requirements.txt includes enum because the pack was developed with Python 2 (meaning pip freeze would include the enum library), but run with Python 3, the site-packages would be searched before the built-in library. But in that case, using the enum; python_version <= 2.7 environment markers from PEP 508 might be a better fix, although it requires pip > 6.0 (which we do anyway, I think) and it requires pack developers to know how to use the option and update their requirements.txt appropriately.

If neither of those are better solutions, this seems reasonable. I do want to point out that this PR does make it impossible for PyPI packages to "override" any of the built-in packages. For instance: if I had a special JSON library that was backwards compatible with the built-in json library it could supply a json module in site-packages so code that imported json would automatically use my library instead of the standard library module. But I can't think of any libraries off the top of my head that do that, and I don't know that we necessarily want to support them if we find ones that do.

So if you think that this is a more reasonable fix for the problem than the solutions above, I approve of it.

[Kami]

Okay, so the enum library is getting loaded from someplace it shouldn't be. Sounds like it's getting loaded from the system's Python environment. Is that correct?

Yes, it's getting loaded from system Python 2.7 virtual environment which is used by all the StackStorm components.

In that case, wouldn't a better fix be to create the pack's virtualenv with the --no-site-packages flag? That's been the default flag for virtualenv for quite some time now.

Yes, that would be ideal. In fact, it's something I tried to do in the past, but sadly our components cross-depend on st2common too much so it's very hard to achieve that without a massive refactor.

Right now Python runner actions and action runner depends on st2actions and st2common. st2common depends on various dependencies which are installed into system virtual environment (including enum).

So the easiest way to make pack virtual environments work is to simply inherit all the system dependencies.

We do that by manipulating PYTHONPATH instead of using --system-site-packages and copying / symlinking dependencies over. Symlinking causes issues on some distros and hard copying dependencies over would mean wasting a lot of space and each time StackStorm gets upgraded, all the virtualenvs would need to be rebuilt.

Or if the pack's requirements.txt includes enum because the pack was developed with Python 2 (meaning pip freeze would include the enum library), but run with Python 3, the site-packages would be searched before the built-in library. But in that case, using the enum; python_version <= 2.7 environment markers from PEP 508 might be a better fix, although it requires pip > 6.0 (which we do anyway, I think) and it requires pack developers to know how to use the option and update their requirements.txt appropriately.

That's what happens right now - enum is only installed when running under Python 2.7 (system StackStorm virtual environment), but as mentioned above and below, main problem is "mixing" those dependencies together.

In short - this is a workaround and the main problem is mixing Python 2.7 and 3 dependencies. For the most part that is not an issue since all other libraries we use work with Python 2.7 and 3.x, but enum is a special case (it's needed by 2.7 where it's a package and it's included in 3.x stdlib where it's a module).

All of that should hopefully become less relevant once we fully support Python 3 end to end (then this won't be an issue anymore).

[blag]

Thanks for the additional explanation - all of that sounds reasonable.