macOS catalina scripting language runtime removal

[arunts2k]

How does macOS Catalina's removal of scripting language runtimes affect Jamf capability to run scripts. Currently we have some python scripts deployed through Jamf.
Will

[nstrauss]

There should be almost no impact. Python 2.7 is still included in Catalina.

Starting with 10.16 Python will not be included and you'll have to install your own. Got another major release to go!

[cpresnall]

They basically gave everyone a year to convert to ZShell, or start deploying our own scripting solutions.

[boberito]

Bash is still included. Just not the default shell. It'll probably get removed down the road. But just not the default. Shouldn't have much impact really especially if you put #!/bin/bash or #!/bin/sh in scripts.

Python down the road will have bigger implications since Python3 is pretty different than Python2. And if you have to install your own Python, then it'll be 3 which people are potentially already doing and so that may be fine.

[tlarkin]

I went through the Apple way to install Python 3 on 10.15. It is very less than desirable, and will not scale (requires Xcode). Apple is swapping the default shell to zsh and bash will still remain.

I would say 10.15 is your OS to start practicing shipping your own languages/frameworks/runtimes and see how it works. I have already shipping Python 3 to my entire fleet after messing with it the Apple way. My plan is, after 10.15 goes GM, to slowly convert all my code to run in my Python 3 env I am already shipping. I am shipping it now to test dependencies and caveats to all clients in my fleet.

Python 2 works 100% fine in 10.15 so far, and so does bash

[tlarkin]

Starting with 10.16 Python will not be included and you'll have to install your own. Got another major release to go!

This is pure speculation, remember that developers use Python to do all sorts of CI/CD automation builds and can bundle Python in their macOS apps to perform certain tasks. Apple may not ship it, but we won't know until 10.16 is in beta next year lol

[gabester]

What about extension attributes that run as scripts? I'd imagine there's more than a couple admins who didn't think to include the shebag and could now be mystified by unexpected results.

[tlarkin]

What about extension attributes that run as scripts? I'd imagine there's more than a couple admins who didn't think to include the shebag and could now be mystified by unexpected results.

What? I mean jamf cannot fix bad practices, that is on the admin

[georgecm12]

When they (eventually) discontinue including runtime scripting languages like python, what would that mean to installer packages that use a python (et al.) preinstall script? I don't have any examples, but I'm sure they are out there.

I guess preinstall scripts should be exclusively shell scripts at this point?

[tlarkin]

@georgecm12

I used a tool called relocatable python to build my env locally of how I wanted it, then packaged it up and deploy it that way via policy. Then at enrollment I have a single zsh script that bootstraps the system

#!/bin/zsh

# this will boot strap the device and ensure Python 3 is installed
# this script will also check for Snowflake dependencies and ensure they are installed

check_for_python() {
# function to test if Python 3 is installed
# limit to 10 loops
for i in "{1..10}" ; do
if [[ $(/opt/snowflake/bin/python3 -V 2>&1 > /dev/null ; echo $?) != 0 ]]
  then echo "Need to attempt to install Python"
  /usr/local/bin/jamf policy -event python3
  sleep 3
  else break
fi
done
}

check_for_depnotify() {
# function to test if DEP Notify is installed
if [[ -d "/Library/Application Support/JAMF/snowflake/DEPNotify.app" ]]
  then echo "DEP Notify Found"
  else /usr/local/bin/jamf policy -event install_dependencies
fi
}


main() {
# call your functions
check_for_python
check_for_depnotify
/usr/local/bin/jamf policy -event main_enroll
}


# call the main

main

That is my only EnrollmentComplete script, I also have health checks for my Python 3 which will flag systems via EA and reinstall my Python env if need be. I chose to put it in /opt because of things like homebrew and developers. I have Python 3 shipped to my entire fleet and is configured at enrollment now, and has been that way since June of this year.

I am now in the process of migrating everything to zsh and Python 3, but have been testing both since June.

[georgecm12]

@tlarkin I was thinking more of commercial software releases that are distributed as a .pkg and that contain a preinstall script that uses python or another runtime language.

(I'm sure Apple's response is "why are you using a .pkg? Distribute your software through the App Store.")

[tlarkin]

Until Apple bans scripts in packages, this is the world we live in. Vendors will have to either ship their own, or rewrite them to use something like zsh as Apple has been shipping a modern-ish version of zsh for a few years now.