Pashua suggestion about alfred-bundler

[shawnrice]

@deanishe, @Ritashugisha : thoughts? Is this easy enough to do with the current Python architecture?

[deanishe]

In a word, no. It won't work in Taurus, either. This isn't really a matter for the Python bundler, as the libraries are in the Pashua DMG, not on PyPi.

There are a bunch of wrappers for various languages included in the Pashua DMG. They're extremely simplistic wrappers, so we're not losing much by not making them available.

Still, simplistic or not, they are kinda the default wrappers (I've always used Pashua.py to interface with Pashua). If we want to make them available in the bundler, they should be copied to the wrappers directory.

In this case, I'd recommend including Pashua.py with the workflow (it's tiny) or copying the relevant code into your own module (about 10 lines), but relying on the bundler to install the app itself.

[shawnrice]

If we want to make them available in the bundler, they should be copied to the wrappers directory.

I could change the Pashua.json file to copy those into the respective wrapper directories. Either that, or we could just include them in the base install of the bundler.

[deanishe]

To be honest, I'd write a new wrapper for Pashua.

It doesn't really do very much, and much of the code is concerned with finding Pashua, which won't work with a bundler-installed version.

[stephen-bunn]

I had the same idea. Since the wrappers for Pashua are low level, we need to create an easier way for developers to use it.

[stephen-bunn]

Hopefully similar to the way the current wrappers work.

[deanishe]

Hmm. That sounds like quite a lot of work.

WRT the Python bundler, I'd sooner we concentrated on getting the issues in #61 done first. You don't fancy having a crack at some of them @Ritashugisha?

Giving people a better Pashua interface than they're used to isn't a priority, imo.

[stephen-bunn]

I'll try to get the CD wrapper up and running this weekend.

[shawnrice]

We can always just push off better pashua wrappers into a future minor release. Maybe Taurus 2 or 3. That way, we can get the bundler out and into production.

[deanishe]

We can always just push off better pashua wrappers into a future minor release

That would be my preference. We're nearly good to go now. No need to keep on adding things to the feature list.

[shawnrice]

We just need to make sure that we don't do anything now that would make an update in Taurus 2 or 3 break a workflow. So this needs to be taken care of in relation to issue #46 (wrappers).

If we just include the stock ones now, then we'd have to make sure that the files are called something else later so that the same syntax doesn't give the author a different interface.

So, we need to decide one thing immediately before we postpone this:

1. We give preliminary wrapper support for Pashau:

• include the wrappers that come with Pashua now,
• keeping those in there as legacy wrappers and introducing our new ones

2. We give preliminary wrapper support for Pashau:

• include the wrappers that come with Pashua now,
• we replace those wrappers with our own in a future release (possibly breaks workflows)

3. We don't include any of the Pashua wrappers and just include ours in a future release.

After we decide this, we should put a "postpone" tag on the issue and close it until Taurus 1 is out (and then re-open).

I say we just go for the third option.

[stephen-bunn]

Third option sounds like the way to go.

[shawnrice]

I'm going to close this and re-open it after we push Taurus 1.