Someone made a successor to Packal to share workflows

[vitor]

2 hours ago, nikivi said:

or the mono repo approach with use of OneUpdater

 

I’ll stress OneUpdater isn’t a solution for monorepo updates; it’s a method-agnostic solution. The whole point of OneUpdater is to not tie you down in any way. That’s why it’s a single node you can copy and configure to get working, and getting rid of it is as easy as pressing ⌫ on said node. It works just as well for monorepos, no repos (any server works), and github releases.

[mjwalfreds]

Hey again all! To answer more of your replies (apologies if they're not all in the right order):

 

Quote

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.

Sorry, didn't mean to dodge this. I don't have plans to right now, but potentially someday‽

 

Quote

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

 

Quote

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.

 

 

Quote

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.

 

 

I love it! Thanks for the suggestion. I'll be incorporating this and will circle back once I have.

 

Quote

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

 

Thanks for sharing that, noted! I think I've got a solution that'll do the trick.

 

Quote

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.

 

Quote

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.

 

 

You are both right. I was naive on that front going into this and the last few days has been enlightening; you've helped me to think about this differently. I will be sure to report any malicious code so that the Alfred team can block it at the greatest level.

 

Quote

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.

 

 

I have a few ideas and will follow up here in the forums if something works as I'd like. I've been convinced by several comments here, namely that having Pacmax laser in on Releases would be a clean & beneficial implementation; I hope to have this live and be pulling from Releases soon. (update: this has been live for a while!)

 

Quote

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.

 

 

@deanishe, I've been working on this over the last day and think I have a great solution to everything you last mentioned. I agree with everything, and I'm excited to post the changes. Briefly, they are by adding a Created By [GitHub Username] which acts as a link to that user's GH profile, styling for the READMEs (we were on a similar wavelength with the lines: I have been working on a  card style for this that I think makes it much clearer), along with other updates which I've made (namely links to the GitHub repository of the post, and clearer language across the site for the different available buttons). It's a work in progress, but again, excited to push more before long!

 

Quote

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.

 

Understandably, and I hope that the most recent and upcoming changes address that.

As always, thanks all, and I hope this has been helpful (as your feedback remains to be).

Cheers,
Max

Edited July 31, 2020 by mjwalfreds
tried to improve readability

[deanishe]

2 minutes ago, mjwalfreds said:

I hope to have this live and be pulling from Releases very soon.

 

Out of interest, what are you planning to do here? Just link to the <repo>/releases/latest page on GitHub or extract the URL of the actual .alfredworkflow file and link to that? 

[vitor]

9 minutes ago, mjwalfreds said:

that having Pacmax laser in on Releases would be a most clean & beneficial implementation

 

That sounds like you won’t support monorepos and will focus on Github Releases, in which case Pacmax is guaranteed to not reach the goals you mentioned. If you want to be a true Packal successor that simplifies the distribution method, you can’t be the one to add the Workflows and you can’t focus on Github alone, plain and simple. Tons of Workflows are not distributed via Github, because not everyone likes (or understand how to use) Github. Some Workflows are only available on Packal, because it offered an upload method. That is a nut that Pacmax is yet to crack.

 

Again, you seem to be a good person with a worthy objective, but you also seem (too) green to package management/distribution systems and community collaboration, and I think you’re making huge mistakes that make me not bet in Pacmax. A third-party closed-source manually updated site with an uncertain future is a hard sell.

 

I’m with @nikivi on this one. The Alfred community has been bitten too many times already by closed-source websites just like that. We don’t need another technological solution, we need an ideological one.

[mjwalfreds]

On 2/23/2019 at 6:32 PM, deanishe said:

Out of interest, what are you planning to do here? Just link to the <repo>/releases/latest page on GitHub or extract the URL of the actual .alfredworkflow file and link to that? 

 

 

I am planning to prioritize the .alfred file types, but have the releases available for download. What do you think?

 

On 2/23/2019 at 7:13 PM, vitor said:

That sounds like you won’t support monorepos and will focus on Github Releases, in which case Pacmax is guaranteed to not reach the goals you mentioned. If you want to be a true Packal successor that simplifies the distribution method, you can’t be the one to add the Workflows and you can’t focus on Github alone, plain and simple. Tons of Workflows are not distributed via Github, because not everyone likes (or understand how to use) Github. Some Workflows are only available on Packal, because it offered an upload method. That is a nut that Pacmax is yet to crack. 

 

Again, you seem to be a good person with a worthy objective, but you also seem (too) green to package management/distribution systems and community collaboration, and I think you’re making huge mistakes that make me not bet in Pacmax. A third-party closed-source manually updated site with an uncertain future is a hard sell. 

 

I’m with @nikivi on this one. The Alfred community has been bitten too many times already by closed-source websites just like that. We don’t need another technological solution, we need an ideological one.

 

 

 

 

Respectfully, I didn't say I won't support monorepos, that I'd focus on GitHub Releases first. By having Pacmax look at Releases I'd be doing the opposite of being the one to manually add the .alfred file types; PM is going to be doing the heavy lifting. I didn't say that Pacmax would ever look at GitHub. It seems like a great place (if not the best place) to start, to me. If it helps: The Share form is not any core functionality. It's a way for people to communicate what packages they'd like to see on the site while I was getting the ball rolling (namely getting the site to be a leaner experience altogether). Automation has always been on my mind, but it was important for me to get feedback from the start. I'm glad I did because without the community's feedback I wouldn't know what to tackle next (and it has helped a lot).

 

Your concerns don't escape me, and I respect them, however this is a new project and I hope anyone interested in it can see that I am scratching the surface. To reiterate, I'm not discounting building beyond GitHub—it feels like a great place to start (and I've got to start somewhere). I'm not expecting to be manually managing the site much longer; that's not realistic—but I didn't make that clear. I hope that better explains my position.

 

All the best,

Max

Edited July 31, 2020 by mjwalfreds
tried to improve readability

[dfay]

FWIW I quite like the idea of basing it on github (despite the fact that I haven’t actually put any finished workflows up there...primarily because they predated my use of github), for a couple of reasons:

1. It’s separate from Pacmax, and will endure even if PM doesn’t, with all the workflows and readmes etc. still searchable
2. It provides a bug reporting system
3. It’s pretty close to universally accepted and is very easy to learn how to use, even if only through the web and without a git client, version control etc.
4. one could set up Pacmax (or something else) to automatically link to everything that looks like an Alfred Workflow, but also add a manually curated / recommended list or set of categories as well.

But as I suggested above, I think it would really help to have a standard recommended structure and docs for getting started, how to share source code as well as .alfredworkflow file etc.  Although the actual bar to using github is quite low, it can appear more intimidating than it actually is if you’re just getting started.

[dfay]

One other note re Pacmax - the design could be tightened up a lot - there’s quite a lot of white space e.g. on every page there’s a big open area with a horizontal line and then the page title in a huge font, and only below that is the actual content.  I’d also prefer one workflow per line in results, rather than needing to read down newspaper columns.  And it would be nice to keep the search box in view even when you scroll down (an issue currently exacerbated by the multi column format).

[deanishe]

7 hours ago, mjwalfreds said:

I am planning to prioritize the actual .alfred file types, but also have the releases available for download as well. What do you think?

 

The .alfredworkflow files are typically under releases. What I meant was: "Are you going to link to the download page or directly to the workflow file?"

What I'm wondering is how you're going to keep Pacmax up to date, such that it's always pointing to the latest version of a workflow. That's easy if you just link to <repo>/releases/latest or some other download page. If you're going to link to an .alfredworkflow file, you'll need to re-scan for changes regularly (or go all-in and use webhooks).

There are also a whole bunch of workflows (already on Pacmax) that don't have any .alfredworkflow file to download. The Node crowd have largely decided to use npm to install their Alfred workflows.

[deanishe]

14 minutes ago, dfay said:

It’s separate from Pacmax, and will endure even if PM doesn’t, with all the workflows and readmes etc. still searchable

 

Critical point right there. No way I'm investing my time in putting my stuff into a proprietary system that may disappear next week.

 

And a site that isn't fully automated is always vulnerable to becoming stale as soon as the operator loses interest or doesn't have the time to manage it any more.

[vitor]

5 hours ago, dfay said:

1. It’s separate from Pacmax, and will endure even if PM doesn’t, with all the workflows and readmes etc. still searchable
2. It provides a bug reporting system
3. It’s pretty close to universally accepted and is very easy to learn how to use, even if only through the web and without a git client, version control etc.
4. one could set up Pacmax (or something else) to automatically link to everything that looks like an Alfred Workflow, but also add a manually curated / recommended list or set of categories as well.

 

None of those is related to Pacmax, though. Those are comments on Github and would still be in place if Pacmax had never been made.

 

5 hours ago, dfay said:

But as I suggested above, I think it would really help to have a standard recommended structure and docs for getting started, how to share source code as well as .alfredworkflow file etc.

 

I’m pretty sure we’ve discussed this years ago in the forum. It doesn’t matter if you have a recommended structure, because each developer will do whatever they think is best (see previous previous XKCD). You can get some of the people to not use their preferred method if they see the advantages of following the recommended system, but truly the recommendation is little more than an established preference of somebody else. Case in point, how seemingly every Workflow author that writes in node insists on sharing their Workflow via npm. You won’t convince them all to change to a specific structure.

 

And that’s the ones you can reach! Packal proves that some people just want to make and share a Workflow. They don’t care about (or will even be aware of) best practices. If you want to be the definitive source where people share Workflows, you cannot impose your own method, you have to be flexible to accommodate everybody else’s (though I do think npm installs are so far off they just might need to be ignored).

 

5 hours ago, dfay said:

One other note re Pacmax - the design could be tightened up a lot

 

Agree with that whole post.

 

5 hours ago, deanishe said:

There are also a whole bunch of workflows (already on Pacmax) that don't have any .alfredworkflow file to download. The Node crowd have largely decided to use npm to install their Alfred workflows.

 

Maybe the solution is not to have direct download links (why would it? Unlike Packal, Pacmax isn’t hosting), but instead a link to the download instructions.

 

5 hours ago, deanishe said:

Critical point right there. No way I'm investing my time in putting my stuff into a proprietary system that may disappear next week.

 

Hence my comment on needing a change in ideology, not technology, in what regards to a system that shares Workflows. All of us have reservations regarding investing into Pacmax, and they all come back to “how do we know it won’t crash like all the others?”. @nikivi did well to insist on the question of open-source. Being proprietary was not the sole cause that sunk the alternatives, but it’s big enough that it’s making us think twice.

[ollieread]

This is definitely interesting.

 

Packal itself could do with a bit of TLC as there do seem to be a lot of errors, typically when trying to search for something. I actually contacted the original author a while back and asked if he'd be interested in me helping him rebuild it as I had a lot of ideas, and well, that's what I do for a living.

 

I actually started working on my own alternative take on it, though I now see that someone else has attempted it. The difference with the work that I was doing was that I was building it to be an actual package manager, so rather than just listing the workflows it could hook up to your GitHub repository and keep up to date, as well as providing a workflow to install from within Alfred. It's something that I'd like to launch at some point, which is my primary reason for being here really.

 

That being said, I'm curious how people are finding this new one? I've had a play with it and it seems mostly basic (I'm not a fan of the design).

 

As a sort of side note, I'd be grateful if someone could point me in the direction of the correct section of the forum where I could make my own post about my proposed alternative, and see if people would still be interested.

[deanishe]

42 minutes ago, ollieread said:

I actually contacted the original author a while back and asked if he'd be interested in me helping him rebuild it as I had a lot of ideas, and well, that's what I do for a living.

 

AFAIK, Shawn had almost finished v2 (Node + MongoDB, IIRC) when life got in the way and he had to abandon it.

 

42 minutes ago, ollieread said:

it could hook up to your GitHub repository and keep up to date

 

Not a simple thing to do, tbh.

 

42 minutes ago, ollieread said:

providing a workflow to install from within Alfred

 

I quite like this idea, but it should use Alfred to install the .alfredworkflow file (the way Vítor's and my updaters do), not try to upgrade workflows itself (the way Packal's updater did). Alfred does a bunch of stuff, in particular migrating your own keywords, when upgrading a workflow. Shawn re-implemented this for Alfred 2 in Packal, and it broke completely when Alfred 3 came out.

 

A lot of Node-based workflows are installed via npm, which straight-up overwrites all user changes on upgrade.

 

42 minutes ago, ollieread said:

I'm curious how people are finding this new one?

 

Just read this thread, I guess.

 

42 minutes ago, ollieread said:

I'd be grateful if someone could point me in the direction of the correct section of the forum where I could make my own post about my proposed alternative

 

This forum (Discussion & Help) is probably the best place.

Edited February 25, 2019 by deanishe

[vitor]

@ollieread We have discussed such a system in the past, more than once (here’s one such case). You’ll see there was at one point a tool that did just that.

 

I’ve thought about it a lot and always circle back to a Homebrew Cask-like system, where you have definitions for Workflows and their download locations that are interpreted by the tool and used as downloads. Yes, the definitions have to be updated when a new version of the Workflow is release (depending on the method), but in practice that can be automated with minimal effort.

 

My most recent idea (which I haven’t yet written about and could tie-in to yours) was a similar system where we’d just have Workflow definitions in a JSON file (or anything, really), such as Workflow Name, Workflow ID, Workflow Source, Author Name, Author Website. It’d be a Github repo, so anyone could contribute info about any Workflows, even the ones that are only hosted on Packal or a personal server. It’d then be a kind of central hub/database where other systems (like a CLI installations utility or a website like Pacmax) could “drink” from.

 

That would be a true community effort that could solve the plaguing problem of abandoned systems for sharing Workflows. Any new one would save themselves a ton of work gathering data and could focus on the interface and features

Edited February 25, 2019 by deanishe
typo

[deanishe]

23 minutes ago, vitor said:

a similar system where we’d just have Workflow definitions in a JSON file

 

Something like this could also form the basis of a native updater in Alfred. As a de jure standard, it'd be as close to universal as we could hope to get.

 

Also no reason they'd all have to be collected in one place. A URL to the metadata file is all you'd need, so people can host their workflows wherever they please. Much like userscripts.

Edited February 25, 2019 by deanishe

[vitor]

1 hour ago, deanishe said:

Also no reason they'd all have to be collected in one place. A URL to the metadata file is all you'd need, so people can host their workflows wherever they please.

 

They can still host wherever they want, but the point is to have a central repository of information, so that every system can benefit from a good glossary. Basically the same system Homebrew Cask uses (which works pretty well). This has the huge advantage that it isn’t dependent on a Workflow’s author to create the definition; anyone can do it (and someone will verify the information is correct), making it the best chance to be a comprehensive database.

 

If you’re worried about the author having control about their own definition, that is easily doable. Again, taken from Homebrew Cask experience, we can have a CLI tool to auto-submit a PR with the updated definition to the repo.

[deanishe]

2 hours ago, vitor said:

If you’re worried about the author having control about their own definition

 

No, not at all. I just think one of the best features of this kind of solution is that it isn't tied to git or GitHub or any particular site or software beyond a webserver.

 

When we've talked about this before, I've always raised userscripts as a model I like. JSON isn't the simplest format, but it's better than XML.

 

It's also a fair bit easier and faster to upload a small metadata file to your own webserver—or just add it to the workflow's repo—than to create a pull request and wait for it to get merged.

 

Having to do the PR dance is why I've never submitted the Alfred-Workflow docset to Dash.

 

Still, I guess someone would write a script to automate submitting the PR at some point, which would take the pain out of it.

Edited February 25, 2019 by deanishe

[nikivi]

5 hours ago, deanishe said:

A lot of Node-based workflows are installed via npm, which straight-up overwrites all user changes on upgrade.

 

This is soo infuriating! As some of the forum members here know, I like to call all my Alfred workflows via external triggers which I add myself on every update of the workflow. Only npm installed workflows often overwrite my changes without any updates to the workflow.. 

I even plan to rewrite some workflows I use that are in node in Go just so I don't have to deal with this.

Edited February 25, 2019 by nikivi

[deanishe]

I've raised that issue with them, but they don't really care.

 

They don't see themselves as writing Alfred workflows. They think they're writing Node programs that use Alfred as a frontend.

 

I'm sure you've noticed that an awful lot of Node developers think absolutely everything should be written in JS (or something that transpiles to JS), and now we live in a world of horrendous bloatware, where apps bundle their own copy of Chrome (a resource hog in itself), and developers think a trivial app that uses 100MB of RAM is "lightweight".

[ollieread]

@deanishe @vitor I actually had a working example locally of hooking it up to Github, it's quite simple.

 

All that it would require would be a file called I don't know, alfred.json to be present in the repository. When a new version is ready, it'd be added to releases tab on GitHub as is the standard process really. That'd fire a webhook to a system telling it that a new version is available. The internal references of the system would pull in the json file for the specific commit that marked the release and updates the information accordingly.

 

This way the system would essentially just store references. The workflows themselves would be hosted on GitHub and downloaded using a direct link, and the site itself would serve as a sort of proxy that catalogues everything. It could also work GitLab and Bitbucket as they both support the same style process I believe.

 

There'd then be a workflow that you'd be able to run to update all workflows or something that lets you pick which to update. This could also be used to search and install. The workflow was the only part I didn't build, but I got a nice API working to return the results.

 

The idea was to create a full package manager, something like composer and http://packagist.org which is for PHP packages, in fact it's modelled on that.

Edited February 25, 2019 by ollieread

[nikivi]

2 minutes ago, ollieread said:

All that it would require would be a file called I don't know, alfred.json to be present in the repository

 

That's a huge issue. Unless Alfred creates this file or the developer doesn't have to think about creating this file, this system won't work. As many would simply not bother adding more friction to their workflow of writing and publishing their workflows. imo

[ollieread]

17 minutes ago, nikivi said:

 

That's a huge issue. Unless Alfred creates this file or the developer doesn't have to think about creating this file, this system won't work. As many would simply not bother adding more friction to their workflow of writing and publishing their workflows. imo

 

That was what I was worried about. I can tell you that in the PHP space composer wasn't widely adopted until some big names started using it. It then very quickly exploded and became the defacto go to for distributing PHP code.

 

There's a command line tool that can be used to create it, and we wouldn't need even half as many options as the composer file can have. To give you an example, here's one from a package of mine: https://github.com/sprocketbox/articulate/blob/master/composer.json

 

I just threw up an example I made ages ago here: https://gist.github.com/ollieread/974544a0cd9d4680f39c6df34a9b17b3

Realistically you'd only need the top 3, I just threw as many options as I could think of at it. A lot of the details like author, version, github URL and even the readme could be inferred from the repository.

Edited February 25, 2019 by ollieread

[deanishe]

Not to be rude, but you don't appear to have thought this all the way through yet. Or you haven't spread your testing net wide enough.

 

28 minutes ago, ollieread said:

it's quite simple

 

28 minutes ago, ollieread said:

All that it would require would be a file called I don't know, alfred.json to be present in the repository

 

That only makes the implementation simple. Now you have to get workflow authors to add a metadata file to their repo just for you, which isn't going to happen.

 

The majority of workflows haven't been updated in years because they're feature-complete and work perfectly fine.

 

A really nasty bug in my Python library that emerged in Sierra broke literally hundreds of workflows. Very few ever received a fix from their developers, so Andrew had to alter Alfred to deactivate them.

 

28 minutes ago, ollieread said:

When a new version is ready, it'd be added to releases tab on GitHub as is the standard process really.

 

That may be the standard GitHub process, but it isn't at all standard amongst workflow authors.

 

Many devs keep all their workflows in a single repo and thus don't use releases. A single alfred.json file isn't going to work there.

The Node crowd, as mentioned above, install their workflows via npm, which also isn't going to work.

 

I believe the whole "just use a metadata file" concept could only work in the way Vítor and I have been talking about. We have put a lot of thought into this already.

Edited February 25, 2019 by deanishe

[ollieread]

2 minutes ago, deanishe said:

Not to be rude, but you don't appear to have thought this all the way through yet.

 

 

I get what you mean, I meant technically simple. The process is one used by almost all other package managers and a pretty standard one, though I do totally appreciate the issues that'd come from trying to have developers add an extra step to their process.

 

I think it'd be the sort of thing that would need to be trialled, and would require some workflow authors to give it a try to see how it works. The only way would be to prove its worth I think. A tool to help automate the process as much as possible may make more people consider it.

 

I'm all up for building something that possibly doesn't succeed because I had fun with my proof of concept. My primary reason for coming here to the forums was to speak to workflow developers to essentially see if they'd consider giving it a go. If no one adopts it fair enough, it's something I'd use, something I think people would benefit from, and something that sounds like fun to build.

[nikivi]

30 minutes ago, deanishe said:

where apps bundle their own copy of Chrome

 

You are right. The problem is that I am/was considering building a desktop app and I was evaluating what to use to build it. As much as I would like to build it in Swift and go full on native, I just can't force myself to touch Xcode coming from VS Code and its amazing editor + vim mode. Xcode is stone age compared to it. And Swift LSP is still immature.

The developer experience of building an electron app in TypeScript and the ecosystem surrounding it is very hard to dismiss. I wish that wasn't the case.

[deanishe]

1 minute ago, ollieread said:

The process is one used by almost all other package managers and a pretty standard one

 

It is, but crucially they all started out that way.

 

There was never a package manager for Alfred, so the main problem isn't a technical one: it's getting developers to add the metadata file you need to workflows that haven't been touched in years.

 

That's why Vítor's "anyone can create the metadata file" method is the only way that I believe could realistically work: if workflow authors won't fix a world-breaking bug as described above (and it was really, really bad), they ain't going to add metadata files for anyone's workflow indexer

 

The only analogue in Alfred is info.plist, which contains a lot of important metadata, but won't help with download URLs and can't be found in any standard location (other than within an .alfredworkflow file).

 

7 minutes ago, ollieread said:

My primary reason for coming here to the forums was to speak to workflow developers to essentially see if they'd consider giving it a go

 

There absolutely is a need for a good workflow indexer/search engine, and there'd definitely be some buy-in, but many of us are also not keen on getting bitten again by another site for workflows that gets abandoned, and likely won't join in until everybody else does.

 

That's what Pacmax and Vítor's solution get right: anybody can add a workflow. Unfortunately, Pacmax currently doesn't get a whole lot else right and Vítor's solution doesn't exist

 

For my part, I couldn't see myself bothering unless it came either from Andrew because that would be official, or from Vítor because he's the maintainer of Homebrew Cask and therefore has a sterling track record at precisely this kind of thing.

 

I don't speak for anyone else, of course.