Relation with `alfred-bundler`? about alfred-workflow HOT 6 CLOSED

Long story short, I advised against including Alfred-Workflow (and any other Python library) in the bundler.

The first problem is that the Python bundler uses pip to install any workflow dependencies (via a requirements.txt file). It also keeps the dependencies for each workflow in separate directories.

This is basically necessary due to the way Python library installs work (no concept of versioned libraries and no simple way to check the dependencies of dependencies and their dependencies etc.).

Adding Alfred-Workflow to the bundler's assets (instead of using bundler.init(), which installs/updates the libraries from a workflow's requirements.txt) would essentially mean having a second library installation mechanism, which is just confusing for the user.

Secondly, I think it's a better idea to call the bundler from within Alfred-Workflow than vice-versa. That way, Workflow.run() can catch and display any bundler errors (and there's a higher-than-average chance of the bundler throwing an error compared to other libraries simply due to its nature).

I have finally put Alfred-Workflow on the Cheeseshop, so you can install/update it with pip.

If you wanted to update all your workflows at once, you could write a script that checks your workflow directories to see if Alfred-Workflow is installed, and run pip install --update --target=. Alfred-Workflow in each one.

I'd advise against that, though. There is no guarantee that the API hasn't changed. I mean, I don't think is has so far, but no promises…

Best to update them one-by-one and check they still work. Being able to use pip should be a big help, though.

from alfred-workflow.

Hmm...some free flow thoughts:

• these considerations for the majority case make sense. However, I think there may be some way to add some functionality for "power-users".
• Alfred-Workflow should not be a dependency like requests, it should be an asset like pip. There is no reason to have multiple copies of it in each workflow's own sandbox.
• Wouldn't it be possible to split Alfred-Workflow into two parts, a la alfred-bundler's wrappers. Have a slim script that lives in the workflow folder. This has the run() function, but not much else. The actual heavy lifting lives in the workflow directory which is in the bundler sandbox. The wrapper (slim in-workflow script) interfaces the Workflow() object from the backend to the user. So, e.g., in zotquery.py I have:

import workflow
wf = workflow.Workflow()
sys.exit(wf.run(main))

The slim workflow.py script, however, functions analogously to bundler.py, and AlfredWorkflow.py functions analogously to AlfredBundler.py.

This way, you have the benefit of using the functionality of alfred-workflow without having its entire footprint duplicated (in my case) 10+ times.

Possible? Feasible? Doable?

from alfred-workflow.

You know I'm willing to help write some code if it is doable. I'm not trying to put all of this on you, especially if you deem it an edge-case. I'm just trying to eliminate hurdles I see in my set-up.

from alfred-workflow.

The question is not can it be done, but why should it be done?

This way, you have the benefit of using the functionality of alfred-workflow without having its entire footprint duplicated (in my case) 10+ times.

That's 1 whole megabyte. If you want to get all hardcore about it, strip the comments and zip the library. As long as you don't need background.py, you can import and use the library from a zip file. You'll probably be down to ~20 KB.

What is the upside of saving, maybe, 100 KB on bundling Alfred-Workflow by requiring 5+ MB of bundler and all the potential problems that poses?

The bundler will fail if there's no net connection, GitHub/Bitbucket is down, there's a bug in the bundler, the user says "no" to installing the bundler or running one of its dependencies (cocoaDialog is required) or one of the websites hosting the resources is down. Even in the best case, it will take at least 10 seconds to install and require the user to allow this and that.

And how does Alfred-Workflow benefit from that?

Why, after working so hard to provide web.py as a 60% replacement for requests to save 2 MB, would I want to turn around and make Alfred-Workflow dependent on the 5 MB bundler with all its inherent potential to fuck up?

Persuade me 😉

from alfred-workflow.

Ah. We are thinking about this from opposite ends. There are two use camps:

1. workflow authors
2. workflow users

For distributing a workflow to users, having Alfred-Workflow distributed with the workflow is clearly superior. I'm talking about opening it up for some customization for an author/user who wants to simplify their personal workflow collection.

So, for me, I already have the bundler; that's sunk cost. And I use Alfred-Workflow all over the place (I have 10 workflows on Packal, and maybe 3-4 more just on my machine). I'm interested in adding the possibility of having one source for Alfred-Workflow that all of those workflows can draw upon. So, I don't want the bundler version of Alfred-Workflow to be the default or anything, I just want that option.

So, I propose this. Why not allow for an author to elect to use a "bundler" version of Alfred-Workflow? For instance, if they are already using the bundler as a dependency, there's little cost to adding Alfred-Workflow as one of the items to download (if any of the possible situation errors occur, it'll halt the workflow no matter what). And once things are downloaded, the internet connectivity stuff doesn't matter.

Blah, blah, blah. I have to eat dinner. Think it over. If you don't think it makes sense, I can jury-rig my set-up no matter what. So it's no biggy.

from alfred-workflow.

If you're using the bundler, you can use its standard Python dependency feature to install Alfred-Workflow from the Cheeseshop.

Just add a requirements.txt file to your workflow with:

Alfred-Workflow==1.8.5
...

to your workflow's root directory, and when you call bundler.init(), it will be installed for that workflow.

Better yet, as it uses pip to do the installation, you can install directly from GitHub.

If you update your requirements.txt file with altered requirements, bundler.init() will notice and update the dependencies.

I'm talking about opening it up for some customization for an author/user who wants to simplify their personal workflow collection.

Install it into your system site-packages using pip install Alfred-Workflow. If you want to use your own custom, local version, symlink it to site-packages. Or add the path of your local copy to sys.path in each workflow.

For instance, if they are already using the bundler as a dependency, there's little cost to adding Alfred-Workflow as one of the items to download

Yes, there is. As noted above, there is an "official" way to install Python packages with the bundler, and that is using requirements.txt and pip via bundler.init().

Adding Alfred-Workflow (or some other package) to the bundler as one of its "assets" muddies the water: "Why are there two ways to install Python libraries? What's the difference?"

The difference is, the "asset" method is shit. Yes, it would be able to install one single, versioned copy of each library, but it would not be able to handle any dependencies it may have (let alone the dependencies of its dependencies). You, the workflow author, would then have to ensure that every dependency, all the way down, is installed.

If you really want to install and use specific versions of the library (or any Python library) as an asset, you can do that by creating your own JSON file to define an asset and handling the import stuff yourself from the path the bundler provides.

I'm interested in adding the possibility of having one source for Alfred-Workflow that all of those workflows can draw upon

As noted above, you can install it using pip in your Python's site-packages or symlink your own version there or symlink each workflow's workflow directory to a single local copy.

We've dealt with this extensively during the development of the bundler, and I'm afraid there is no sane way to add Python (or Ruby) libraries via the bundler due to the way the languages' de facto dependency installers work. To do so, we'd have to reimplement large parts of pip/gem, which is way beyond the scope of the bundler project.

For better or worse, both those communities have rejected the idea of centralised, versioned libraries and the standard is to give each application/plugin/workflow its own private copy of any libraries it needs :(

Seeing as this is actually a bundler issue, you might want to add an issue on its repo, and see what Shawn and the other Stephen think: it's ultimately not really my decision to make.

But as noted, and for the above reasons, I will argue against adding Python/Ruby libraries as "assets".

from alfred-workflow.