Shipping Your Own Python to macOS
With the announcement at Catalina’s release that some third party run times will be removed, and the fact that Python 2 is end of life it is time to ship your own. Just like everything in tech, there are many ways to accomplish this. I have been using a tool for about over a year now called relocatable python.
The reasons I chose to use relocatable python
were pretty good ones in my opinion. They are:
- Easy to use
- Builds full self-contained Python environment
- Easily able to wrap it up in a standard installer PKG
Once you have it in an installer package, you can use whatever tools you want to distribute it. Every management tool and application deployment tool should be able to deploy an installer pkg.
quick start guide
- Download the repo from the link above from the directory you wish to download it to
|
|
- Look at the
--help
argument to see what we can do. Ensure you are in the repo folder.
|
|
- Lets make the folders where we want to create our Python environment
|
|
Note: I made two directories there and will explain later why. You can put this anywhere you want. In this example I am using
/usr/local
but if you want it away from user space you can place it in say something like/opt
- Now lets build our first Relocatable Python Package
|
|
Note: you will see the tool output a bunch fo stuff in the terminal, let it finish
- Next we will create our symbolic link to make this easier when we want to call this environment in code
|
|
- Finally, you just need to use your preferred packaging tool to add this folder path, including the symbolic link in an Apple Installer Package.
Caveats, and things to consider
As XKCD has already pointed out, managing a Python Environment can be a chore
Installation Path
In the above example there are definitely some things to know and consider. To keep the quick start guide less esoteric
I just used /usr/local
as the directory to deploy my Python 3 environment into. In practice, I actually do not do this.
I deploy to /opt/myorg
instead to my fleet. I have worked with lots of clever developers over the years, and they need to
often install tools to do their job. Those tools often go into /usr/local
, thus I stay out of that area. I let user’s
have that space to themselves.
Which Python?
I also have Xcode on this Mac, and I also installed the Python3 Xcode tools as well.
|
|
When you install that, it does put python3
in the standard $PATH
and if your code calls that path or if you just type
python3
in the shell, without typing the full path, you will get that Python environment. Some planning will be needed
as well as some decision-making by the IT Admin/Engineer that wants to deploy their own Python. There is no gold standard
answer, so you will need to figure out what is the best answer for your team and Org.
Requirements.txt file
The author of Relocatable Python did something clever, but some may have missed it. They made an assumption that if you
were to build a Python3 environment to deploy to your macOS fleet you might want the objc
bridge, and tools like xattr
So, those tools are just included in the default argument. You should note this just in case you plan on customizing your
Python3 package to add more Python packages to it. You will need to add those back. One can view the documentation
on how this works.
To see what packages you have you can use pip
to do so:
|
|
This will output a giant list of packages you have installed. If you want to add more packages you should also include
the ones the author of Relocatable Python gave you. When using a requirements.txt
file it strictly follows that file.
Anything not listed will not get installed.
Refer to the --help
output we used earlier to add the requirements.txt
file
|
|
Mac Admin Community Python
There also those in the Mac Admin community who are already maintaining a public Python3 package which anyone can just go download and/or contribute to. You can find the repo here. This method does make design choices for you. If these design choices are okay with you, then this would be the easiest and fastest way to just ship your own Python3 environment to your fleet.
Virtual Environments
This is also an option, but it seems most Orgs want to ship their own isolated Python and if they need to create a venv
they can do so from the Python they have shipped. Personally, I hae never used a venv
outside of my on personal development.
I chose to ship the environments, so I can control it. If you want to control venv
to a fleet I think shipping your own
is the best to start and then build your venv
off of that.
Tracking Versions, upgrades, and remediation
I think in the past ~3 years I have found 2-4 systems total that had bad Python environments I was shipping. I am not exactly sure why they broke, it could have just been a failed installation. So, I started tracking the status and version I was shipping in a simple Jamf EA. Here is a quick example I wrote in the shell:
|
|
This script will return a false
value for any broken Python environment. So, I have an ongoing policy that will reinstall
my Python3 environment scoped to this EA with a value of false
so this is intentional. I highly recommend you never use
blank values in anything you use. Always be explicit with your data, you will never know what a null
or blank string value
will affect, down or up stream.
So, you can track it by the version and create policies to auto remediate any broken Python3 environment you encounter
Conclusion and acknowledgements
You have many options to choose from. It really is a lot easier than one might think, and if you have any questions or
trouble, please join us in #python
and #python-beginners
on MacAdmins Slack and various community members can assist
Acknowledgements:
- Greg Neagle
- Mac Admins Slack
- Mac Admin Community