Patrick Stadler

:+1:

Right now you can extend transports like this: ``` javascript Transport.prototype.getuid = function(args, opts) { opts = this._parseOptions(opts); return this.__exec('getuid', args, opts); }; ``` This is far from optimal, what...

It's not a good idea to store user data into a folder controlled by npm, or introducing an obscure env variable. What if you would just extend your Flightplan class...

So you'd like to see some kind of tooling ecosystem like `gulp` or `grunt` has? Why not. I'm planning to refactor Flightplan at some point, because the current codebase is...

Hey @ravi If you're still interested in this subject, please make a quick proposal in the form of code snippets how you'd like to write extensions and how to load...

Hi @akloeber 1. `plan` is an instance of `Flightplan`. You need to register commands on the `Transport` class. 2. how to handle commands which are only available for either SSH...

You could try to execute `plan.run(task, target, options)`, fly does the [same](https://github.com/pstadler/flightplan/blob/master/bin/fly.js#L95). Please note that I never tried this, but I understand the use case, so please let me know...

Another idea is to write your tasks like this: ``` javascript plan.local(['build-phar', 'deploy'], ...); plan.local(['deploy'], ...); ``` When you now run `fly deploy`, the `build-phar` task is executed as well.

@basz thanks for reporting back. @ravi see #45. I wouldn't call this a discussion, as you didn't explain me that the current implementation is not enough for your needs. So...

I think this can be closed with #33. Please reopen if this is still a problem.