Replace Python 2 Convert workflow with standalone Convert workflow

[techouse]

The original deanishe/alfred-convert is amazing, but ever since macOS 12.3 removed Python 2 it's been affected by deanishe/alfred-convert#91.

Realizing that, I decided to write my own using Dart and compile it to a standalone native binary.

It converts physical units and fiat currencies, however, it does not convert cryptocurrencies.

The binary is signed and notarized by Apple.

[vitorgalvao]

@techouse This repo will eventually be deprecated in favour of the Alfred Gallery. If you’d like to properly submit it for inclusion, the forum post explains how.

I see you have several workflows. I was looking to include them, starting with this one. However, off the bat before testing I’ve noticed a few barriers to inclusion in the Gallery:

• It includes an auto-updater.
• It’s only compiled for Intel, not Apple Silicon.
• It uses Workflow Environment Variables instead of Workflow’s Configuration.

You can see more explanations and the reasoning for all of the above in the linked forum post.

Furthermore (these should not affect inclusion, but still worth pointing out):

• Why are you starting every command with arch?
• Always prefer with input as argv over with input as {query}

Let me know if you have any questions. The forum might be a better place for it since there can be a specific topic for it.

[techouse]

This repo will eventually be deprecated in favour of the Alfred Gallery. If you’d like to properly submit it for inclusion, the forum post explains how.

OK, makes sense. I'll close this PR and submit a new one to that repo.

I see you have several workflows. I was looking to include them, starting with this one. However, off the bat before testing I’ve noticed a few barriers to inclusion in the Gallery:

• It includes an auto-updater.

I'm not sure why that is a bad feature? I've simply inherited it from my old Python 2 workflows.

• It’s only compiled for Intel, not Apple Silicon.

To compile Dart to arm64 one has to have an arm64 machine. I'm still on an x86_64. I could set up a compilation Github action, however, it seems a bit overkill.

Furthermore (these should not affect inclusion, but still worth pointing out):

• Why are you starting every command with arch?

So that an x86_64 compiled binary can run on arm64.

[vitorgalvao]

Auto-updating has to be removed for security reasons and to avoid conflict with the Gallery’s own update system.

An Intel binary can only run on an Apple Silicon Mac with Rosetta, which not everyone has or wants. Having only one architecture doesn’t give people a choice and will lead to confused users.

I haven‘t checked the workflows thoroughly yet, so please do check the linked blog post for the requirements.

[techouse]

Auto-updating has to be removed for security reasons and to avoid conflict with the Gallery’s own update system.

I see. I'll disable this feature in the following releases.

An Intel binary can only run on an Apple Silicon Mac with Rosetta, which not everyone has or wants. Having only one architecture doesn’t give people a choice and will lead to confused users.

I've configured Github actions to compile and notarize the binaries, however, currently, Github only offers x64 macOS runners and to compile Dart for arm64 they'd have to be compiled on arm64 macOS. At the moment arm64 macOS runners are in public beta.

I haven‘t checked the workflows thoroughly yet, so please do check the linked blog post for the requirements.

I've read through it and it shouldn't be an issue apart from the x64 bin which is currently the limiting factor.