ollieread

That's why I mentioned composer. PHP didn't start out with a package manager, though we had PEAR at some point, but no one really likes that. I've writing PHP for almost 16 years and I think composer has only really existed/been widely used for the last 4 or 5. I know that you don't know me and it probably won't mean anything, but if I were to launch a platform, in whatever way, it would be sponsored and ran by my company. I literally write web applications every day, it's my job, and that won't be changing for a long time. Perhaps the code could even be open source so people could contribute to it, but that's another matter. That's a very good point. It seems like they were all built based on a single persons idea. Perhaps the way to go forward would be to speak to users and workflow authors alike and figure out exactly what people would want from a site for workflows. Maybe it'd be best to build an indexer/search engine for workflows and go from there. I think that if that worked and it became widely used and popular, that'd open up an avenue for approaching the package manager option as there'd be an audience and level of credibility.

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.

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.

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

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.