Make awm ready for 2017

[claui]

I love Packal, and I’ve grown to like awm, the CLI tool by Jonathan Wiesel.

 

The response was not exactly overwhelming when Jonathan pushed awm out three years ago.

But that was 2014, and since then CLI tools have gotten some traction, and today they are considered sexier than ever (I think). 

Anyway, I can’t stop dreaming of a version of awm that is ready for the year 2017.

 

As a humble first step, I’ve just finished up three tiny PRs. They do absolutely nothing but remove the gunk from the `npm install` process.

But hey, it’s a start!

 

Regards,

Claudia

[vitor]

Oh, hey! Welcome to the forums (second post, but still)! In case you’re not recognising me from the picture/username, I didn’t restrain myself to that single trope.

As a small note, Packal is pretty much abandoned (the creators haven’t had much time to spend on it for a long while) and mostly in maintenance mode. Many things are broken, like search (I always get a database error). Using it as a central repository might not be the best bet, as of now.

I’ve been thinking for many months now how we could have a Homebrew-Cask-like system for Alfred Workflows. I never think of Homebrew-Cask itself because in my view Workflows need to have a GUI install to show the important README. However, if you’re interested in kicking some ideas around, I’m up for it. I think most (maybe even all) Homebrew-Cask maintainers are Alfred users.

I’d mostly care for an approach that would not rely on a centralised system for getting Workflow information, lest it die as well. I’ve made OneUpdater which is a self-contained Workflow-agnostic way to check for Workflow updates. It does not matter how you build the workflow, you can just plug it in, configure it once, and then forget it. If you ever want to get rid of it for some reason, you delete a single node and it’s done. Those are the “why”s of it: easy setup, no impositions on your code, no maintenance, easy to get rid of.

For an Alfred CLI installer, I’d like to keep those values. Have something that would continue to work even if the maintainers abandoned it.

Anyway, welcome again, nice to see you here. Just wanted to offer support to discuss ideas if you ever think about implementing your own system.

Have a nice day!

[deanishe]

I don't see awm as a particularly viable tool for the community at large. 

 

It's not just that it's a command-line tool (which is fine for developers, but not ideal for normal users), but it also requires nodejs. 

 

As such, it will not run out-of-the-box on OSX, but requires installing Homebrew and nodejs (that's the easiest way). Bundling nodejs with it is out of the question, as it's well over 100MB.

 

Any solution aimed at the broader Alfred community needs to be trivial to install, imo, without such huge dependencies.

 

(To be honest, I don't really get why people write workflows in nodejs to begin with on account of the hundreds of MBs of dependencies your 100KB workflow now has.)

Edited February 27, 2017 by deanishe

[vitor]

1 hour ago, deanishe said:

I don't see awm as a particularly viable tool for the community at large. 

 

It's not just that it's a command-line tool (which is fine for developers, but not ideal for normal users), 

 

In my view of a Homebrew-Cask-like CLI tool, I’m thinking of the same target. Meaning the people that use HBC are the same that would use such a tool, I’m not necessarily including other users. Although now that I think about it, after the tool is made there could be a Workflow that takes advantage of it, making it accessible to non-developers.

 

1 hour ago, deanishe said:

but it also requires nodejs.

 

As such, it will not run out-of-the-box on OSX

 

Agreed there. That’s a huge downside for me. I have nodejs installed, but whenever I see a Workflow written in it I tend to shy away from it anyway.

 

Although to be fair, we all write Workflows mostly for ourselves and then make them fit a larger audience. If someone is more comfortable with node and making the Workflow for themselves, we can’t really fault them for sharing it in that state if someone else finds it useful.

Edited February 27, 2017 by vitor

[deanishe]

8 hours ago, vitor said:

there could be a Workflow that takes advantage of it, making it accessible to non-developers.

 

Yeah. If it's designed in a reasonable way (e.g. parseable output), it should be possible to build a workflow around it.

 

8 hours ago, vitor said:

Although to be fair, we all write Workflows mostly for ourselves and then make them fit a larger audience.

 

Totally understand that. But if you're setting out to build something for the community at large, nodejs is a really bad choice.