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)