• 
      

    Fix the Mac installer to truly work in all macOS installs.

    Review Request #8665 — Created Jan. 24, 2017 and submitted

    Information

    RBTools
    release-0.7.x
    dc8f501...

    Reviewers

    We've had some.. fun.. figuring out the compatibility problems with the
    Mac RBTools installer, but we finally have it figured out. The paths for
    the Python 2.7 build of RBTools worked only if you had installed Python
    from python.org using their installers, and probably didn't work well
    otherwise. However, Python 2.6 was still taking precedence, meaning that
    most people could still use RBTools, in theory, but since we built the
    RBTools wheel with Python 2.7, argparse never got added as a dependency,
    so unless the user had previously installed a much older version of
    RBTools that explicitly added that, they couldn't run RBTools.
    
    All that is fixed.
    
    We now explicitly install the packages for the Mac Installer payload
    using the system Python, ensuring that everything ends up in
    /Library/Python/2.{6,7}/site-packages, which should be checked no matter
    which variant of Python is being used. This provides the greatest
    compatibility across a range of macOS versions and a range of Python
    setups.
    
    We also build a wheel per Python version, ensuring dependencies are
    correctly installed for the installer payload. This fixes the argparse
    on Python 2.6 problem.
    
    Finally, the /usr/local/bin/rbt script has been updated to no longer
    hard-code a Python binary path. Instead, it's been replaced with
    "/usr/bin/env python", which will get the version of Python being used
    on the system. This helps in the case where you have custom rbt scripts
    installed for your Python environment, and want them to work with
    RBTools.
    
    In the end, this should finally provide a universal installer that users
    can depend on.

    Built the installer and tested on a system with Homebrew, one with the
    Python installer, and one vanilla.

    Posted the latest version of this change for review with using only the
    system Python (no third-party installer), and another with the official
    Python from python.org.

    Manually inspected the package contents to check that all paths and
    scripts were as expected.

    Checked that building in a virtualenv didn't break the package in any way.

    Description From Last Updated

    I've find the inlining of variable references using $name to be pretty error prone. Can we use ${name} instead, so …

    daviddavid
    reviewbot
    1. Tool: Pyflakes
      Ignored Files:
          contrib/installers/macosx/build-mpkg.sh
      
      
      
      Tool: PEP8 Style Checker
      Ignored Files:
          contrib/installers/macosx/build-mpkg.sh
      
      
    2. 
        
    chipx86
    reviewbot
    1. Tool: PEP8 Style Checker
      Ignored Files:
          contrib/installers/macosx/build-mpkg.sh
      
      
      
      Tool: Pyflakes
      Ignored Files:
          contrib/installers/macosx/build-mpkg.sh
      
      
    2. 
        
    david
    1. I have one comment, but it applies in a number of places:

    2. contrib/installers/macosx/build-mpkg.sh (Diff revision 2)
       
       
      Show all issues

      I've find the inlining of variable references using $name to be pretty error prone. Can we use ${name} instead, so that the variable reference doesn't just melt into the rest of the line?

    3. 
        
    chipx86
    reviewbot
    1. Tool: Pyflakes
      Ignored Files:
          contrib/installers/macosx/build-mpkg.sh
      
      
      
      Tool: PEP8 Style Checker
      Ignored Files:
          contrib/installers/macosx/build-mpkg.sh
      
      
    2. 
        
    david
    1. Ship It!
    2. 
        
    chipx86
    Review request changed
    Status:
    Completed
    Change Summary:
    Pushed to release-0.7.x (737d452)