Don't use shutil backport on py3

Review Request #10047 — Created June 29, 2018 and updated

sgallagh
RBTools
release-1.0.x
4ebd931...
rbtools

On many distributions (including Fedora and RHEL 7), the backports.shutil package doesn't exist for python 3.x because it's meaningless. Instead of unconditionally including it, use the appropriate import for the python version in use.

Submitted this very review using rbt post on python3 with this patch applied.

  • 2
  • 0
  • 1
  • 0
  • 3
Description From Last Updated
Instead of checking the version, how about just a try/except? try: from shutil import get_terminal_size except ImportError: from backports.shutil_get_terminal_size import ... david david
Can we call this install_requires instead of runtime_reqs? The "runtime" makes me think that this will actually be computed at ... david david
Checks run (1 failed, 1 succeeded)
flake8 failed.
JSHint passed.

flake8

sgallagh
Review request changed

Change Summary:

Corrected formatting.

Commit:

-37bf520fabe78600b7c83f500a2c47257a4ec6d3
+4ebd93159240ed8ad9515646c67cc7479e3ea153

Diff:

Revision 2 (+17 -8)

Show changes

Checks run (2 succeeded)

flake8 passed.
JSHint passed.
david
  1. 
      
  2. rbtools/commands/status.py (Diff revision 2)
     
     
     
     
     

    Instead of checking the version, how about just a try/except?

    try:
        from shutil import get_terminal_size
    except ImportError:
        from backports.shutil_get_terminal_size import get_terminal_size
    
    1. I wanted to keep the implementation in the code and the implementation in setup.py in sync. Just in case (for example) shutil.get_terminal_size() started showing up on python2, but with different semantics. I can do the try/except if you prefer, though.

    2. The try/except is our usual method for this case. It avoids having to make assumptions about when things show up (even if they're pretty well-understood). Plus it's about to differ anyway -- see below.

  3. setup.py (Diff revision 2)
     
     

    Can we call this install_requires instead of runtime_reqs? The "runtime" makes me think that this will actually be computed at runtime, whereas the list will get evaluated at the time that the package is being built.

    1. Well, it was the list of things that have to be available on the system at runtime to operate. Calling them install_requires suggests to me that they are needed for performing the installation itself, which they are not.

    2. In the modern Python world, we don't want to build a list of requirements based on the version anyway. It will break now, as we ship a single Wheel that works on Python 2 and 3 (built using 3, meaning this dependency won't end up in the package).

      Instead, we'll need to use the new Python version specifiers to specify when a particular version applies. This looks like:

      install_requires=[
          'colorama',
          'six>=1.8.0',
          'backports.shutil_get_terminal_size; python_version<"3.0"',
      ]
      

      Modern versions of pip and easy_install will respect this. The packages (both eggs and wheels) will be built with metadata tagging that dependency along with a Python version, and the installer will only install it on the appropriate version.

      (I just tested this on RBTools with both eggs and wheels and verified shutil only installed on 2.7.)

    3. How modern are we talking about? I'm trying to make sure that RBTools keeps working on RHEL/CentOS too, which are stuck on older versions. I suppose if I have to, I'll just carry specialized patches for those releases.

    4. setuptools 8.0 and pip 6.0 both should have this support. That puts it at December 2014. We're using these version specifiers going forward in our setup scripts, though of course distro packages can always do something a bit more custom.

  4. 
      
Loading...