Jump to content
claui

Make awm ready for 2017

Recommended Posts

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). :lol:

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

Share this post


Link to post

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!

Share this post


Link to post

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

Share this post


Link to post
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 by vitor

Share this post


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

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...