Future macOS versions won't bundle any scripting language runtimes

[nikivi]

Source.

I think it's a big deal and would probably mean saying no to running any python/ruby based workflows (of which there's a few) unless they bundle a runtime with them or point to assumed python installation (in path) I guess. 

I don't much use these languages and write all my workflows in Go (with AwGo) to get around this problem.

Edited June 3, 2019 by nikivi

[vitor]

2 hours ago, nikivi said:

I think it's a big deal and would probably mean saying no to running any python/ruby based workflows (of which there's a few) unless they bundle a runtime

 

You’ve exposed the problem and solution in the same sentence!

 

2 hours ago, nikivi said:

I don't much use these languages and write all my workflows in Go (with AwGo) to get around this problem.

 

I’m not sure I understand. Presumably you didn’t write your Workflows in Go to avoid a problem that was unknown before today (unless you have access to privileged Apple information).

It’s not like there aren’t ways to bundle those languages as single executables. Ruby has a few (that I never tried) such as Ruby Packer. I’d be surprised it there isn’t something similar for Python. If there isn’t, this is an incentive to get on it.

[xilopaint]

3 hours ago, vitor said:

It’s not like there aren’t ways to bundle those languages as single executables. Ruby has a few (that I never tried) such as Ruby Packer. I’d be surprised it there isn’t something similar for Python. If there isn’t, this is an incentive to get on it.

 

I'm completely unaware of this discussion but wonder how big the workflow size could get by doing this.

[vitor]

16 minutes ago, xilopaint said:

I'm completely unaware of this discussion but wonder how big the workflow size could get by doing this.

 

Significantly bigger. It wouldn’t be a trivial increase in size.

 

There is an obvious solution, which is for Alfred to bundle the runtimes (I can already see the Node developers asking for theirs to be included as well). That solution is not all bad; it would at least ensure consistent versions (right now they depend on your macOS version). Speaking of which, might be a good idea to ping @Andrew, in case he’s not yet aware of the news. There’s about a year to make a decision. The document that describes this change is the macOS 10.15 Beta Release Notes.

 

@deanishe is also bound to have an opinion on this.

 

Tangential to these changes, ZSH will become the default shell! No more old Bash.

[dfay]

I actually like the idea of Alfred providing runtimes but my scripting is almost exclusively in python and Applescript...

 

Beats this

 

[deanishe]

2 hours ago, vitor said:

Tangential to these changes, ZSH will become the default shell! No more old Bash.

 

Well that's good news. I'm also happy to see that the new OS is called Catalina and therefore follows my My Name Is Earl naming scheme (my devices are named Earl, Randy, Darnell etc.).

 

The rest kinda sucks, though, doesn't it?

 

I've just tried bundling a couple of Python workflows. Minimum size seems to be ~3MB. ~10MB seems a more realistic size for non-trivial workflows. Which are about the same binary sizes I'd expect from Go (all Go executables are statically-compiled).

 

In any case, Alfred-Workflow doesn't work when bundled: it expects to be able to call its own background.py file directly. That could be worked around, though.

 

As I understand it, Perl and pals aren't gone in Catalina, but they will be gone in some later version. So I wonder what this means for Alfred 5? Backwards-compatibility with many workflows won't be possible, as the other software they depend on will have gone.

 

I don't really see Andrew integrating any of Perl, Python, Ruby, PHP or Node into Alfred in the same way that Sublime Text has its own embedded Python. If he did integrate a runtime, I presume it would be JXA (built-in) or Lua (tiny and designed for embedding). Python is also designed for embedding, but it's pretty big (you'd need to include the whole standard library, too).

 

Perhaps Alfred PowerPack users will have to get used to installing Homebrew, and most workflows will have the same skanky setup experience that Node ones do?

Edited June 4, 2019 by deanishe

[Andrew]

I think the really good news with this is that Apple are recommending bundling, which, basically means scripting will continue to work on Mac... It could have gone the horrific route of deprecating macOS altogether and making iPadOS run on the Mac.

 

This is a deprecation in 10.15, so default scripting languages should remain in the OS for the time being, which will give me time to contemplate the best approach for this for Alfred. Alfred may just download the runtimes needed.

 

Cheers,

Andrew

[raguay.customct]

I think it would be best to have the option to install runtimes by Alfred. For hard-core users, they will already have a runtime for most of their favorite scripting languages and they could just point Alfred to them. But, the change also means that homebrew will need a major change. No more `/usr/local` directory usability! The user will have to keep everything in their home directory. Unless I miss read the post, which is very likely.

[xilopaint]

What is the average Alfred user profile? Is he/she aware of Homebrew? If so I'm in favor of promoting Homebrew Python/Ruby rather than bundling runtime. There's no difference in UX when you have Python installed via Homebrew and I don't think the comparison with node is accurate. With node you have the workflow installed in some shady path.

 

I'm more curious to know what will be the future of Alfred-Workflow. Will it be converted to Python 3 since there's no longer advantages to stick with Python 2?

Edited June 4, 2019 by xilopaint

[deanishe]

1 hour ago, xilopaint said:

I don't think the comparison with node is accurate

 

Not all Node-based workflows want to be installed via npm. A lot of them are built like regular workflows, but they need /usr/local/bin/node.

 

I think the comparison is a good one because the latter kind of workflows get a lot of support requests for getting Node & npm working. If someone downloads your .alfredworkflow file and it doesn't work, they expect you to help them get it to work (even though it's Homebrew/Node they need help with).

 

1 hour ago, xilopaint said:

I'm more curious to know what will be the future of Alfred-Workflow.

 

Alfred-Workflow 2, I suppose. A complete rewrite that supports Alfred 4 and Python 3 only. That'll enable me to rip out a lot of the Alfred 2-era cruft and improve the API.

[deanishe]

2 hours ago, raguay.customct said:

No more `/usr/local` directory usability!

 

I think (and hope!) you may have misread the post. The release notes don't say anything about /usr/local/bin.

Edited June 4, 2019 by deanishe

[raguay.customct]

27 minutes ago, deanishe said:

 

I think (and hope!) you may have misread the post. The release notes don't say anything about /usr/local/bin.

 

> During upgrades to macOS 10.15, files and folders stored at the root-level of a volume are moved aside to /Library/SystemMigration/History/Migration-UUID/QuarantineRoot/. (45378791)

 

Since it is being moved away, it doesn't say it will re-create it. Most likely, all root access will be completely cut off, which makes sense in light of their goal of tighter security. Anything in a Quarantine location can not be executed. Nothing says the user will be able to get to this area either. Therefore, we will have to wait and see if it completely blocks all installations outside of the Applications folder and the home directory, but I would assume that is their intention.

[deanishe]

That just mentions upgrade, not what happens thereafter.

 

Also, isn't /usr/local a default directory? The system doesn’t put anything in it, but I think it’s there.

[raguay.customct]

If they were going to keep it, why remove it to a quarantine location? Really, this is all speculation. It will be interesting to see where it all goes. But, if they ever merge iOS with iPadOS and  macOS, this would be a good starting place. Get everyone used to not having the root directories. `/usr/local` is a linux/Unix convention. macOS doesn't have to keep it.

[deanishe]

1 hour ago, raguay.customct said:

If they were going to keep it, why remove it to a quarantine location?

 

I don't know. Perhaps they haven't implemented the logic yet that decides what to keep and what not.

 

1 hour ago, raguay.customct said:

`/usr/local` is a linux/Unix convention. macOS doesn't have to keep it.

 

macOS is a certified UNIX…

[raguay.customct]

8 minutes ago, deanishe said:

macOS is a certified UNIX…

 

Assuming they want to keep certification as a UNIX standard system. I hope they do, but it's hard to say. If they eventual merge all the platforms, UNIX certification will be lost then as well.

[duffkiligan]

duffkiligan (bin)$ pwd
/usr/local/bin

duffkiligan (bin)$ ls
2to3			apollo			fuzzy_match		lzcmp			nettle-pbkdf2		pkcs1-conv		pyvenv-3.7		xzdec
2to3-3.7		asn1Coding		gdbm_dump		lzdiff			node			pod			sandbox-pod		xzdiff
ansible			asn1Decoding		gdbm_load		lzegrep			npm			psktool			sexp-conv		xzegrep
ansible-config		asn1Parser		gdbmtool		lzfgrep			npx			pydoc3			srptool			xzfgrep
ansible-connection	brew			gnutls-certtool		lzgrep			ocsptool		pydoc3.7		terraform		xzgrep
ansible-console		cask			gnutls-cli		lzless			op			python3			unlzma			xzless
ansible-doc		easy_install-3.7	gnutls-cli-debug	lzma			p11-kit			python3-config		unxz			xzmore
ansible-galaxy		ebrowse			gnutls-serv		lzmadec			p11tool			python3.7		wheel3
ansible-inventory	emacs			goldin			lzmainfo		packagesbuild		python3.7-config	xcodeproj
ansible-playbook	emacs-26.1		idle3			lzmore			packagesutil		python3.7m		xz
ansible-pull		emacsclient		idle3.7			nettle-hash		pip3			python3.7m-config	xzcat
ansible-vault		etags			lzcat			nettle-lfib-stream	pip3.7			pyvenv			xzcmp

duffkiligan (bin)$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.15
BuildVersion:	19A471t

/usr/local/bin is there after the upgrade, it even contains things I have installed in it before the upgrade.

Edited June 4, 2019 by duffkiligan

[deanishe]

16 minutes ago, duffkiligan said:

/usr/local/bin is there after the upgrade, it even contains things I have installed in it before the upgrade.

 

Thanks for clearing that up!

[vitor]

7 hours ago, deanishe said:

If he did integrate a runtime, I presume it would be JXA (built-in)

 

I’m betting on osascript to remain installed. At least until (if) they decide to kill it off in favour of Siri Shortcuts on macOS.

 

6 hours ago, xilopaint said:

What is the average Alfred user profile? Is he/she aware of Homebrew? If so I'm in favor of promoting Homebrew Python/Ruby rather than bundling runtime.

 

Even if the average user is aware of Homebrew, there is still a huge segment that is not, and those are important users.

 

As for relying on Homebrew, my recommendation would be to check for any third-party package manager and use that one. There are still people who use MacPorts, and there are people who have strong feelings against Homebrew. If any of those is an Alfred user, I don’t know.

 

1 hour ago, raguay.customct said:

If they were going to keep it, why remove it to a quarantine location?

 

This is not the first time they’ve done so, though I haven’t checked if they did it every time. There were some complaints during the transition from Mavericks to Yosemite, in that the system upgrade could take many hours. They moved /usr/local out of the way, and the process of putting it back was dog slow.

 

Whatever their reason for moving it out of the way, it is indeed done for their convenience and only as part of the upgrade process.

[xilopaint]

7 hours ago, deanishe said:

Alfred-Workflow 2, I suppose. A complete rewrite that supports Alfred 4 and Python 3 only. That'll enable me to rip out a lot of the Alfred 2-era cruft and improve the API.

 

Can we expect this for 2019?

[dfay]

No it will be in the MacOS version that launches o/a Sept 2020.

 

Edit: oops misread what you were asking about

Edited June 4, 2019 by dfay

[deanishe]

9 minutes ago, xilopaint said:

Can we expect this for 2019?

 

Depends on whether I can be bothered or not. It's a lot of work for not much payoff.

[politicus]

Hi,

 

I am fine with what I can do with my hundreds of Alfred workflows with my current OS version but one or two applications I use every day require a newer OS if I want to upgrade them. 

And I do want to upgrade them.

 

I haven't been very active on Alfred forums these last months but I remember reading about one workflow (whose I do not remember the name) stopped working because the user had installed a newer OS. I am not sure but It was probably because of a bug in a beta version of the newly launched OS.

 

As I want to continue to use as many Alfred workflows I am using now, I was wondering if, from your experience, there is a "better" OS version to choose in terms of workflows compatibility?

 

Thank you.

 

@Andrew Do you mind sharing your OS version? Might be of great help 😀 

[deanishe]

2 minutes ago, politicus said:

if, from your experience, there is a "better" OS version to choose in terms of workflows compatibility?

 

Mojave's probably the sweet spot. It doesn't have all the awful features of Catalina that have crippled so much software, and very few apps are Catalina-only.

[vitor]

55 minutes ago, politicus said:

I was wondering if, from your experience, there is a "better" OS version to choose in terms of workflows compatibility?

 

Not really. The best macOS version for a particular Workflow is bound to be whatever version the Workflow author is in, because that’s the one they’ll make sure it works in.

 

34 minutes ago, deanishe said:

Mojave's probably the sweet spot.

 

That said, I agree here. Mojave is the newest non-completely-broken macOS.

 

57 minutes ago, politicus said:

@Andrew Do you mind sharing your OS version? Might be of great help 😀 

 

I’d bet Alfred’s team has multiple macOS versions available, to be able to evaluate reported bugs. I’d also bet they have little choice but to run the latest (Catalina in this case) most of the time, because those only gain more users while the older macOS versions lose them, and the teams needs to chase new bugs.

 

38 minutes ago, deanishe said:

very few apps are Catalina-only.

 

More than we’d like, unfortunately (I see them added to Homebrew Cask). Authors of new open-source native apps tend to target Catalina (as in “I’m starting now, I’ll only support the newest”) and there are also commercial apps whose newest point releases are Catalina-only. It’s also common to see “our app is now discontinued, as it will never be updated to 64bit”.

 

I have seen iOS app authors go iOS 13 only and then backtrack and readd support for iOS 12, but haven’t heard of anything like that on macOS.