Someone made a successor to Packal to share workflows

[nikivi]

It's called Pacmax. Saw it posted on Reddit.

 

I was actually thinking of building it but glad that I don't have to. 😅

[deanishe]

Saw that, too. Looks good, but I'd feel much better about it if the gent who built it were at least a forum member.

 

Packal was never official, but it was built in close communication with the Alfred team.

 

4 hours ago, nikivi said:

I was actually thinking of building it

 

Yeah, it's somewhat similar to the frontend I've been planning to build (though my plan includes a spider, not just manual submissions). I've been waiting for Alfred's built-in update mechanism to crystallise, so there's a standard metadata format to work with, rather than having to build a (hit-and-miss) spider.

Edited February 20, 2019 by deanishe

[vitor]

29 minutes ago, deanishe said:

Looks good, but I'd feel much better about it if the gent who built it were at least a forum member.

 

Packal was never official, but it was built in close communication with the Alfred team.

 

I feel the same. Right now, there’s not much difference between this and the old http://alfredworkflow.com/ or the still current https://github.com/Derimagia/awesome-alfred-workflows.

 

And with a manual adding process, it doesn’t really make me want to submit there. Am I supposed to just dump almost 50 Workflows on Pacmax’s creator’s lap?

 

It’s a nice effort, but I wonder if at this point it isn’t making the situation worse, by fragmenting the community even more.

[deanishe]

30 minutes ago, vitor said:

It’s a nice effort, but I wonder if at this point it isn’t making the situation worse, by fragmenting the community even more.

 

Yeah. In that regard, I'd be much more amenable to a fully-automatic, no-user-input site that just scans for GitHub repos tagged with alfred-workflows.

Workflow discovery is definitely a problem (a forum is a pretty crappy format for that), but "here's another site to submit your workflow to" worsens the situation, rather than improves it, even if the site itself is good.

 

The "Awesome Alfred Workflows" list is a different matter, imo, as it's a curated list, not a free-for-all (and importantly, maintained). And given decent curation—and I believe Dave is doing a good job in that regard—there's definitely value in it.

Edited February 20, 2019 by deanishe

[nikivi]

I think my alfred workflow list is a bit cleaner than Dave's but thats my opinion.

 

The tool I wanted to build was also what Dean had in mind. It should be automated to get info from GitHub first and foremost with additional submit ability.

 

I wanted to build some hook in system to map a workflow to github releases and have the site update from that.

Although not all distribute workflows via github releases and some dont distribute via github at all.

Edited February 20, 2019 by nikivi

[nikivi]

It would be cool if the author made Pacmax open source so maybe we improve on that.

I also don't want to submit workflows to some closed source tool that I have no control over.

[deanishe]

4 minutes ago, nikivi said:

I also don't want to submit workflows to some closed source tool that I have no control over.

 

Why did you post the link in the first place, then, if you think it's a bad idea to submit workflows there?

Edited February 20, 2019 by deanishe

[nikivi]

26 minutes ago, deanishe said:

Why did you post the link in the first place, then

 

To get a discussion going and hear what the community thinks. I am not the one to judge what people should do, they can decide for themselves.

 

For all we know, the tool might be using some crawler (spider) under the hood already or has one planned.

 

And for another point, it's currently the best website to fill Packal's void. And it has a search that works. Packal is also closed source for whatever reason. 

Edited February 20, 2019 by vitor
Merged posts. No text was altered.

[vitor]

4 minutes ago, nikivi said:

For all we know, the tool might be using some crawler (spider) under the hood already

 

It’s not:

Quote

To share a package on Pacmax, just shoot us the repository link; we’ll look that over to make sure it’s not malicious and then post it.

 

2 minutes ago, nikivi said:

it's currently the best website to fill Packal's void.

 

Why do we need a website to fill Packal’s void? What’s wrong with the Github lists? Why not just grab one of those and make a website (automated)?

 

Also, people are still submitting to Packal, so there’s no void yet, just a badly plugged leak.

 

Unrelated, if you post in a row you should edit your post instead. Otherwise the thread quickly becomes hard to read.

[deanishe]

18 hours ago, nikivi said:

To get a discussion going and hear what the community thinks. I am not the one to judge what people should do, they can decide for themselves.

 

That's a fair point.

 

Still, it seems a bit odd to post a site that you say you don't want to submit your own workflows to.

 

Now I look more closely, I think it questionable that the site doesn't mention workflow authors at all. Every page says "Maxwell Jordan White" but never mentions the people who're providing the content that makes the site anything but completely pointless.

 

Notably, there's also a  big "Donate to Me!" link, but none for the workflow authors (which Packal always had).

 

Quite likely an oversight by Max, but all the same, not super cool.

Edited February 21, 2019 by deanishe

[Vero]

Morning all! I've suggested to @mjwalfreds to join this conversation, so he can chat with some of our most experienced and active community members, so I'm sure he'll come and introduce himself soon

 

Cheers,
Vero

[mjwalfreds]

Hi all, I am thrilled to see this post & that my original post was unhidden. Sorry for the late reply; I had no idea it was visible or that this post was here until this morning. I'm going to do my best to follow up on each point now; please let me know if there is anything else that I can touch on more.

 

Thanks for the mention @Vero and @nikivi  for posting this thread!

 

Quote

Saw that, too. Looks good, but I'd feel much better about it if the gent who built it were at least a forum member.

Quote

Packal was never official, but it was built in close communication with the Alfred team.

 

Understandable—I've been a long-time lurker and have been talking some via email with an Alfred admin (who has been great, by the way). I've been excited to hear from the community at large, which is why I wound up posting what I did to Reddit. Hopefully, now I'll be able to better communicate here.

 

Quote

Yeah, it's somewhat similar to the frontend I've been planning to build (though my plan includes a spider, not just manual submissions). I've been waiting for Alfred's built-in update mechanism to crystallise, so there's a standard metadata format to work with, rather than having to build a (hit-and-miss) spider.

 

This sounds great and if you're interested I'd love to learn more about that. With the spider being a hit or miss, that was my major concern and why I opted (for now) to have things be manually submitted; automation has absolutely been on my mind though. And, even the possibility of having major contributors be given more control over adding packages to PM. Anyways, I am all ears and would love to learn more.

 

Quote

I feel the same. Right now, there’s not much difference between this and the old http://alfredworkflow.com/ or the still current https://github.com/Derimagia/awesome-alfred-workflows.

 

And with a manual adding process, it doesn’t really make me want to submit there. Am I supposed to just dump almost 50 Workflows on Pacmax’s creator’s lap?

 

It’s a nice effort, but I wonder if at this point it isn’t making the situation worse, by fragmenting the community even more.

 

 

I agree with Deanishe that the AAW repo is a different matter; I've actually recently contributed to Awesome Alfred Workflows because I think it's great and wanted to see it be a little sharper. I believe in making the adding of packages more accessible for not just developers but non-developers; which is where I think I was sort of coming from when I decided to undertake a sort of Packal-like site.

 

As an aside: That XKCD is too real. Haha.

 

Quote

Now I look more closely, I think it questionable that the site doesn't mention workflow authors at all. Every page says "Maxwell Jordan White" but never mentions the people who're providing the content that makes the site anything but completely pointless.

 

Quote

Notably, there's also a big "Donate to Me!" link, but none for the workflow authors (which Packal always had).

 

Quote

Quite likely an oversight by Max, but all the same, not super cool.

 

I see what you mean and that is definitely an oversight on my part. Honestly, I added it because I felt like once and a blue moon someone might help pay for even a portion of the web hosting which really isn't much; I've probably invested more time than anything. How would you suggest I add Donation options for the developers? I'd love to incorporate this. I've also been working on making it more clear on each post who made what and where they can find more from them.

 

In closing, I want to do anything and everything I can to automate the submissions of packages & better highlight the developers. This is new to me, but I do want to make the most of this. I know I started out with the aim to make a more usable site, and I think I'm in the right direction, but I look forward to improving it further. It was great reading the above and I look forward to more! If anyone would like to reach out to me about more in-depth feedback or feature suggestions, about anything we've discussed here or otherwise, please don't hesitate to shoot me a message here or at hi@pacmax.org.

 

Cheers,

Max

 

P.S. I apologize for my wonky formatting here. I wrote this all in MD and it didn't convert very well. I am sure I will come around to the editor here in the forums. I also didn't maybe go as in depth as I'd like to but I have a few projects going on for work that I need to get to now. So, to reiterate, please reach out if there's anything I can improve on.

[nikivi]

@mjwalfreds Have you thought about open sourcing Pacmax? Is there a reason you wish to keep it closed source? I ask because I see no value in keeping it closed source unless you somehow plan to make money off this that is not just donations.

If the tool was open source, it would be much easier to actually make it the 'best' tool all Alfred users use and love. I or some other Alfred user/developer may chip in and maybe add a PR for a proof of work spider or some UI/UX changes. List goes on. 

I think it's one of the reasons Packal died off. The maintainer got busy with life and had no time to support Packal in a meaningful way. Open source solves this issue if there is any interest in the tool and I reckon there is an interest in a tool like this unless @Andrew has something official planned for the future. 

Edited February 21, 2019 by nikivi

[deanishe]

2 hours ago, mjwalfreds said:

How would you suggest I add Donation options for the developers?

 

Shawn (the developer of Packal) had a field for a PayPal email or URL (I don't recall exactly). That would presumably require user accounts, though. I don't think donation links for workflow authors is important, but I think you really ought to at least mention the workflow authors.

 

Every comparable site I know, from packagecontrol.io to npmjs.org to packages.debian.org lists the developer/maintainer.

 

2 hours ago, mjwalfreds said:

I wrote this all in MD and it didn't convert very well

 

Have you tried Vítor's workflow? It's tuned for this forum and the awful, buggy Invision editor.

 

2 hours ago, mjwalfreds said:

I am sure I will come around to the editor here in the forums.

 

You might get used to it, but I don't think anybody likes it. It's riddled with annoying bugs.

[deanishe]

On 2/21/2019 at 8:07 PM, mjwalfreds said:

This sounds great and if you're interested I'd love to learn more about that. With the spider being a hit or miss, that was my major concern and why I opted (for now) to have things be manually submitted; automation has absolutely been on my mind though.

 

I've just been testing Pacmax. It doesn't appear to like "monorepos", where a user keeps all their workflows in a single repo (or perhaps I didn't wait long enough).

[vitor]

23 hours ago, mjwalfreds said:

I believe in making the adding of packages more accessible for not just developers but non-developers

 

I’ve reread that multiple times and can’t decipher what that mean in practical terms. 1. How are you making the adding os packages “more accessible”? 2. In what way are the current solutions not accessible enough? Right now your solution seems less accessible, because you’re a gatekeeper to whatever gets added to the site.

 

And you haven’t answered my previous point: 3. if I want to submit to Pacmax, am I supposed to dump almost 50 Workflows on your lap lap for you to go through? 4. Are you the one who decides which Workflows are added to the website? 5. If yes, why, what’s your criteria for inclusion or refusal?

 

If you are curating, that would indeed make Pacmax the same as Awesome Alfred Workflows and far from a Packal replacement. Packal wanted to be the central repository where everyone could share their Workflows. The biggest problems with Packal are that it asks for too much information for a submission and is buggy. Had it been bug-free, we wouldn’t even had noticed it was abandoned nor would we be needing an alternative. But it still works, even if crippled. Manual addition, by comparison, will only work for as long as you’re excited with the website, and that makes me worry for its longevity.

 

That’s my biggest eyebrow raise with Pacmax right now: it isn’t clear (and specific) about what it is or what it wants to be. Awesome Alfred Workflows is shameless about being a subjective biased list: it’s a particular kind of list (from the “Awesome” series) connected to a specific person, and mentions curation right away. Packal is automated and lets anyone submit whatever they want. Pacmax, I don’t know.

 

The optimistic news is you seem like a nice person with a true desire to make something good. Make no mistake, I see Pacmax as having positive potential. But it’s common for projects to die for lack of enthusiasm, and with the subject of sharing Alfred Workflows, every time that happens we get worse off. People submit to what is popular at the moment, and when that dies off most don’t jump on the next thing, so we keep losing Workflows in the process.

 

So I hope you understand where my worry comes from and why I have some reservations (and many questions) about what Pacmax is and what it wants to be. But I also want to make it clear that I thank you for at least trying, and I understand these may only be your first steps.

[deanishe]

Umm, I take back my previous comment. It doesn't really work with any workflow.

The "download" link just points to GitHub's <repo>/zip/master link, which is a zipped copy of the source code, and not appropriate for the vast majority of workflows.

For some repos, there may be an .alfredworkflow file inside the zip that can be easily installed. For others, such as Vítor's monorepo, there'll be dozens of .alfredworkflow files in there.

In many other cases, to actually install the workflow, the user will either have to:

1. Copy the unzipped directory to Alfred's workflow directory,
2. Copy a subdirectory of the unzipped repo to Alfred's workflow directory, or
3. Install a complete Node/Go/Swift/whatever development environment in order to build the workflow.

That one of these steps is required will not be obvious to non-technical users, let alone which one.

 

Just changing the .zip file to .alfredworkflow file will not work in any situation.

For a very large proportion of workflows that aren't in monorepos, the .alfredworkflow files that Pacmax should be linking to for download are found in the GitHub releases, where built programs are supposed to be.

 

1 hour ago, vitor said:

I’ve reread that multiple times and can’t decipher what that mean in practical terms.

 

I presume that means that people only have to paste a URL in the box instead of submit a pull request (which is a complex procedure if you're not familiar with git and GitHub).

 

@mjwalfreds I've noticed that someone has submitted a bunch of my workflows to Pacmax. I'd like to ask you to remove them at this time.

 

I don't want to be fielding support requests from people who downloaded a copy of the source code via Pacmax instead of the .alfredworkflow file from GitHub releases that's explicitly linked in every workflow's README, and don't understand what's going on.

Edited February 22, 2019 by deanishe

[deanishe]

49 minutes ago, vitor said:

The biggest problems with Packal are that it asks for too much information for a submission and is buggy.

 

My main issue with Packal was always that it required me to do everything twice. Every time I updated a workflow, I had to update it on both GitHub and on Packal. The later bugginess aggravated this, but having to do everything twice was always the sticking point.

 

Pacmax has the right idea with "paste repo URL here and that's it". Unfortunately, it doesn't currently do the right thing(s) with repo URLs.

[dfay]

Presumably if any automated solution based on github is to work, there would need to be a standard for how Alfred github repos are structured.

[mjwalfreds]

Hi again all! Sorry for the late reply, again. Frankly, my sleep schedule is 💩. I need to work on that.

@deanishe, re: PayPal - One idea I've had is making it so that repos with PayPal URLs, eg https://www.paypal.com/donate/?token=[...], display a button to make it clearer to the reader that it's an option. This could be a way to continue on the no-accounts-necessary path. What do you think?

 

Quote

Have you tried Vítor's workflow? It's tuned for this forum and the awful, buggy Invision editor.

I haven't, but I've got it now and will use it for this reply. It looks great, kudos @vitor. I'm glad that I'm not alone in not digging the editor.

 

Quote

I've just been testing Pacmax. It doesn't appear to like "monorepos", where a user keeps all their workflows in a single repo (or perhaps I didn't wait long enough).

You're absolutely right. I had noticed this in another instance; we're only able to grab the entire repo as it stands—I've added it to my todo list!

@vitor, to answer your points 3 & 4:

 

Quote

And you haven’t answered my previous point: 3. if I want to submit to Pacmax, am I supposed to dump almost 50 Workflows on your lap lap for you to go through? 4. Are you the one who decides which Workflows are added to the website? 5. If yes, why, what’s your criteria for inclusion or refusal?

Re: This is a great question and I apologize for having missed it. Put briefly, I have no interest in curating the site. My #1 concern with submissions has been digging into the repos to try to confirm that the files aren't malicious for the end-user. Beyond that, I believe diversity is good, and my whole goal here has been to try and make sharing and finding workflows easier on everyone. 2 things come to mind for me on this: 1) I want to be clearer about this so I am going to work on that language, and 2) I'd like anyone's feedback about what would make a repository "malicious"; I'll use that to improve the info on the About page, and to better hone my submission workflow. The last thing I want to do is introduce something dangerous to someone who is maybe not looking at the source or even the READMEs.

 

Quote

That’s my biggest eyebrow raise with Pacmax right now: it isn’t clear (and specific) about what it is or what it wants to be. Awesome Alfred Workflows is shameless about being a subjective biased list: it’s a particular kind of list (from the “Awesome” series) connected to a specific person, and mentions curation right away. Packal is automated and lets anyone submit whatever they want. Pacmax, I don’t know.

So to answer the above, anyone can submit whatever they want on Pacmax. The last thing I'd want to do is build something that aims to improve the discoverability of the amazing workflows that you and others offer the community, only to be selective about what's posted. I simply have no desire to do that

 

Quote

The optimistic news is you seem like a nice person with a true desire to make something good. Make no mistake, I see Pacmax as having positive potential. But it’s common for projects to die for lack of enthusiasm, and with the subject of sharing Alfred Workflows, every time that happens we get worse off. People submit to what is popular at the moment, and when that dies off most don’t jump on the next thing, so we keep losing Workflows in the process.

So I hope you understand where my worry comes from and why I have some reservations (and many questions) about what Pacmax is and what it wants to be. But I also want to make it clear that I thank you for at least trying, and I understand these may only be your first steps.

If I've seemed unclear about "what Pacmax is and what it wants to be" it's probably only because, frankly, my initial mission was to create a more usable site for developers and non-technical people who haven't gone beyond installing Powerpack. It's a work in progress, but I do think it's improving, especially with everyone's feedback. I hope I've addressed your questions though. It's important to me that I have, so if not please let me know and I'll do my best to.

 

Quote

Just changing the .zip file to .alfredworkflow file will not work in any situation.

For a very large proportion of workflows that aren't in monorepos, the .alfredworkflow files that Pacmax should be linking to for download are found in the GitHub releases, where built programs are supposed to be.

Thank you for outlining this! I'll do my best to explain this for non-technical users. I'm also going to work on how Pacmax pulls the files (eg the GitHub releases).

 

Quote

I presume that means that people only have to paste a URL in the box instead of submit a pull request (which is a complex procedure if you're not familiar with git and GitHub).

Yup! That's all I meant. 🤘

 

Quote

My main issue with Packal was always that it required me to do everything twice. Every time I updated a workflow, I had to update it on both GitHub and on Packal. The later bugginess aggravated this, but having to do everything twice was always the sticking point.

Pacmax has the right idea with "paste repo URL here and that's it". Unfortunately, it doesn't currently do the right thing(s) with repo URLs.

Yes, this is what I'm trying to spare people from. And thanks for seeing that; usability is important to me and I want to make it simple to browse and share on PM because that sort of double-step/bugginess gets old fast. I'm going to work on the way PM works with the repo URLs as well as how the site handles submissions. What might be easier for developers to submit (if they decide to, I mean)? Would a multiline form be better? Perhaps once I get monorepos working, developers may prefer to work that way. But for the time being and for devs who might not, I'm wondering what I can do. Again, open to suggestions. As @dfay mentioned, until there's some sort of standard I am going to do my best to fetch the files a number of ways (to fit the few preferences people have).

@deanishe Sure thing. I will un-publish your repositories. If I may though, as I expect to have this cleaned up before very long at all, I'd love to get at you so that I can confirm it is working as you'd expect it to. You do amazing work and I'd hate to not see your contributions on Pacmax; it'd be a major loss to me. Mind if I shoot you a message here once I have, to see if I have?

Thanks again for everyone's feedback. I hope I was clear; I may make an edit if I think I can be more concise.

Cheers!

Edited February 22, 2019 by mjwalfreds
fixed a link and some excess space

[deanishe]

58 minutes ago, dfay said:

Presumably if any automated solution based on github is to work, there would need to be a standard for how Alfred github repos are structured.

 

Not necessarily, but currently an automated solution would require a fairly intelligent spider. You'd probably want to extract most workflow metadata from info.plist, but your spider would have to be able to cope with "monorepos" like Vítor's, which contain a whole bunch of workflows—including .alfredworkflow files—as well as repos that contain a single workflow with the .alfredworkflow files in GitHub releases.

I've been planning to build a (mostly) automated workflow indexer for some time, but I've been holding off in the hope that a native workflow updating mechanism will be added to Alfred. Building a spider that finds and parses info.plist files isn't particularly challenging, but without any standard, finding the corresponding .alfredworkflow file to download and install becomes tricky: Some workflows have their own repo, with .alfredworkflow files in releases. Others have the .alfredworkflow file in the repo root. Some don't contain an .alfredworkflow file at all.

If Alfred gets a well-designed native workflow update mechanism, which is what I'm hoping for, everything becomes super-simple: the corresponding metadata file would contain all necessary info for an indexer, so you wouldn't have to crawl a whole repo, nor apply any heuristics. In any case, the download URL would necessarily need to be present in the file.

After what has happened with Packal, one of my absolute requirements was also that all workflow metadata be de-centralised, and that the indexer require zero human interaction, such that anyone can set up an indexer of their own if the operator of the original one gets bored or otherwise doesn't continue (or if they just fancy building an indexer).

Moderation of submissions is of marginal value, imo, especially wrt security, as there's nothing a mere indexer can do to prevent users installing a workflow anyway: Any malware would need reporting to Andrew immediately, so he can block it effectively at the Alfred level.

[nikivi]

You haven’t answered my question about potentially making the site open source. But I guess the answer to that is no which is fine too. 

[vitor]

55 minutes ago, mjwalfreds said:

One idea I've had is making it so that repos with PayPal URLs, eg https://www.paypal.com/donate/?token=[...], display a button to make it clearer to the reader that it's an option.

 

https://www.paypal.com/donate is a bad pattern to search for and encourage, as PayPal doesn’t like that use of donate and has cracked down on users who use it in this manner. I forget the specifics, but I think it has something to do with donate being for nonprofits, not tips. The correct one to use in this case is https://www.paypal.me/.

 

1 hour ago, mjwalfreds said:

to try to confirm that the files aren't malicious for the end-user.

 

You’re fighting a losing battle. Presumably you don’t understand every programming language, nor are you going to sift through and understand hundreds of lines of code to find something malicious. If someone wanted to introduce malicious code to a Workflow, they could also obfuscate it. As with every software, trust in the code comes with trust in the developer. Which is not to say code shouldn’t be audited — it should — just that I think you taking that up on yourself won’t be a fruitful use of time.

 

59 minutes ago, mjwalfreds said:

I hope I've addressed your questions though.

 

For the most part, yes. Thank you. Though it remains the question of how would my Workflows be added to your site, since I use the monorepo method.

[deanishe]

12 hours ago, mjwalfreds said:

One idea I've had is making it so that repos with PayPal URLs, eg https://www.paypal.com/donate/?token=[...], display a button to make it clearer to the reader that it's an option

 

That sounds like it would work well. For my part, I don't much care about donation links (or do I call them "tip links" now?). It was just a really nice touch by Shawn when he made Packal.

 

But I really do think that workflow authors should be fairly prominently credited. I mean, you're pulling in screenshots and the entire README. Basically a whole lot of their stuff.

 

Take @otherguy's  Airports workflow (a fairly extreme example):

 

 

It's got my name in there (thanks, @otherguy!), but the author's name is nowhere.

 

And the README's written with the expectation that it'll be read on GitHub where it's clear that "me" refers to @otherguy.

 

On Pacmax, with no border around the contents of the README and your copyright notice, it looks rather like "me" refers to you.

 

Beyond that, searching by author is a great way to find workflows: if you think a workflow is really good, chances are you'll like other workflows by the same person, too.

 

12 hours ago, mjwalfreds said:

Perhaps once I get monorepos working, developers may prefer to work that way. But for the time being and for devs who might not, I'm wondering what I can do. Again, open to suggestions

 

No idea, tbh. I gave this quite a lot of thought, and my "solution" was to wait and see if Alfred gets a native workflow update mechanism. Then there'd have to be some form of metadata file that is available at a URL and which contains the workflow download URL. Pop the URL of that file in the indexer and Bob's your uncle.

 

FWIW, monorepos aren't compatible with a lot of workflows. Apart from devs who just prefer to have one workflow per repo, quite a lot of workflows are based on my Python library, and its update mechanism uses GitHub releases, thus requiring one repo per workflow.

 

12 hours ago, mjwalfreds said:

If I may though, as I expect to have this cleaned up before very long at all, I'd love to get at you so that I can confirm it is working as you'd expect it to. You do amazing work and I'd hate to not see your contributions on Pacmax; it'd be a major loss to me. Mind if I shoot you a message here once I have, to see if I have?

 

Thanks very much. My workflows all use GitHub releases for downloads, which is a very common case.

 

Really, you can do pretty much as you please with my workflows. That's why I released them under the MIT licence.

 

I just don't want to be fielding questions from folks who've downloaded a copy of the source code via Pacmax instead of the .alfredworkflow file and don't know what to do with it.

[nikivi]

One thing that would be useful to add to Pacmax (and something current Alfred documentation lacks on the website) is how can you distribute your freshly made workflows to people.

Perhaps Pacmax can mention the two ways (single repo per workflow distributed via GitHub releases aided by AwGo or some other library) or the mono repo approach with use of OneUpdater or some other mechanism although I only know OneUpdater and use it myself for my mono repo. I have both mono and single repo workflows I distribute.

I think having this information I mentioned above, perhaps even on Pacmax Share page with some examples of these approaches in action would be very useful.

Edited February 23, 2019 by nikivi