Remove `BundleID` requirement for import about awgo HOT 4 CLOSED

A better approach would be to have a function like this

wf = New() is there to allow the library-level functions to work without you having to create your own Workflow. Requiring an InitWorkflow() function to be called rather defeats the purpose of that, so no-go.

I agree that import-time side effects suck. Either I will make initialisation lazier or strip out the library-level functions and the default wf Workflow.

from awgo.

Requiring an InitWorkflow() function to be called rather defeats the purpose of that, so no-go.

Another option would be to have flexible default behavior for the built-in Workflow. I.e. have it detect that the developer hasn't put it inside a real bundle yet and have it automatically skip bundle management tasks like caching. This would actually be a much more helpful reaction to it discovering it has no BundleID than erroring out and terminating execution.

That way they can rapidly develop the user interaction parts of the Workflow using stdout. Then once the program is fully polished, it can be built into an executable for use in the real Alfred bundle.

This option may be preferable because it means you don't have to change the syntax for your awgo package and current developers can experience this benefit free of charge without changing their current code. It's honestly how I expected the package to behave when I first downloaded it and I was surprised when it started hitting me with BundleID errors for trying to develop locally through stdout.

You could also have a awgo.Debug = True flag that Workflow checks. This way it would error out if the developer tries to put it inside Alfred without specifying BundleID, which you would still want it to do.

from awgo.

That way they can rapidly develop the user interaction parts of the Workflow using stdout

I always use a terminal to develop workflows. It's simple enough to source a script that sets the required variables.

I will remove the import-time requirement for a bundle ID because no library should explode on import. The runtime requirement will remain, however. AwGo needs the bundle ID (and cache path) for most of its functionality.

it means you don't have to change the syntax for your awgo package and current developers can experience this benefit free of charge without changing their current code

Too late for that, I'm afraid. I've refactored AwGo massively in the v0.14 branch.

Check out the new Env interface that now underpins everything.

Currently, the Option to pass a custom Env to New() isn't exported, but I'll change that (and rejigger New() not to immediately panic if the environment variables are missing).

Then you can pass your own Env to New() to set the bundle ID etc. programatically. I'll probably export the mapEnv type to make it even easier.

from awgo.

The default *Workflow and import-time requirements are gone in v0.14.

from awgo.