Jump to content
nikivi

Future macOS versions won't bundle any scripting language runtimes

Recommended Posts

Posted (edited)

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 by nikivi

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post

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

 

Beats this

 

python_environment.png

Share this post


Link to post
Posted (edited)
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 by deanishe

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post
Posted (edited)

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 by xilopaint

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post
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…

Share this post


Link to post
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.

Share this post


Link to post
Posted (edited)
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 by duffkiligan

Share this post


Link to post
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!

Share this post


Link to post
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.

Share this post


Link to post
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?

Share this post


Link to post
Posted (edited)

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

 

Edit: oops misread what you were asking about

Edited by dfay

Share this post


Link to post
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.

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...