Vision for getting started etc.

[jasonkuhrt]

I was chatting with @joneshf on IRC about this and he suggested I bring it up with the project.

The getting started story for psc is not ideal. It at least requires:

1. install haskell
2. install purescript
3. install node
4. install grunt
5. install grunt utils
6. understand the interop between grunt and psc, psc-make, etc.

It seems like it should be more along these lines:

$ brew install purescript && psc dev

Maybe it would help if the ps community defined an ideal vision and then worked backwards from there to accomplish the engineering feats required. I think Meteor and Elm are exemplary in regards to their workflow stories. Maybe Clojure/Clojurescript too, I don't know. It does seem that right now the biggest challenge to working with ps is the space between:

1. Wanting to try building a project with it
2. Building/deploying/running a a project with it

Ideally, the gap should be almost invisible to the user.

If ps is not approachable then it really does not matter how good it is. People do not want to consult a reference on how to build a project, buffer that knowledge, then flush it at once, and repeat. They want short trial-and-error cycles with really quick and useful feedback.

[jdegoes]

npm install purescript is more realistic because npm is cross-platform, whereas every OS / distro has its own family of package managers which are preferred by different segments of users.

Something like: brew install node && npm install purescript is probably more attainable.

-- 
John A. De Goes
Follow me @jdegoes

On December 7, 2014 at 10:21:45 AM, Jason Kuhrt (notifications@github.com) wrote:

I was chatting with joneshfon IRC about this and he suggested I bring it up with the project.

The getting started story for psc is not ideal. It at least requires:

install haskell
install purescript
install node
install grunt
install grunt utils
understand the interop between grunt and psc, psc-make, etc.
It seems like it should be more along these lines:

$ brew install purescript && psc dev

Maybe it would help if the ps community defined an ideal vision and then worked backwards from there to accomplish the engineering feats required. I think Meteor and Elm are exemplary in regards to their workflow stories. Maybe Clojure/Clojurescript too, I don't know. It does seem that right now the biggest challenge to working with ps is the space between:

Wanting to try building a project with it
Building/deploying/running a a project with it
Ideally, the gap should be almost invisible to the user.

If ps is not approachable then it really does not matter how good it is. People do not want to consult a reference on how to build a project, buffer that knowledge, then flush it at once, and repeat. They want short trial-and-error cycles with really quick and useful feedback.

—
Reply to this email directly or view it on GitHub.

[jasonkuhrt]

@jdegoes Yeah fair enough.

And actually I should clarify something. I see a lot of need for improvement in what happens after installation. Yes install can be improved, but the experience of buliding/watching/rebuilding etc.;

The emphasis on bower is strange for people that want to make servers with node, adding additional indirection/friction.

[garyb]

The bower thing is a little unfortunate, but npm is unsuitable for distributing PureScript libraries due to the way it handles dependencies, and the fact it is intended specifically for JavaScript packages.

We went with bower as it is mostly a thin wrapper around git, and we didn't want to make yet another package manager specifically for PureScript.

[jasonkuhrt]

@garyb I believe the fragmented nature of JS package management for client/server was part of the reason that Elm decided to roll its own. I don't have enough feedback yet to suggest anything for PS specifically, but maybe later. In regards to npm here is a spot check I just ran:

⧑ npm search purescript
NAME                     DESCRIPTION                                                AUTHOR
generator-purescript     Yeoman generator                                           =joneshf
grunt-purescript         Compile PureScript files.                                  =garyb
gulp-purescript          Run the PureScript compiler                                =ethul
gulp-purs                Compile PureScript                                         =mietek
pulp                     A build system and package manager for PureScript projects =bodil
purescript-ajax          purescript-ajax ===============                            =joneshf
purescript-chalk         PureScript wrapper around Chalk.                           =joneshf
purescript-const         Const typeclasses and instances for PureScript             =mankyki
purescript-contravariant Contravariant typeclass for PureScript                     =mankyki
purescript-distributive  Distributive Library implmentation for PureScript          =mankyki
purescript-featurespec   Write high level features.                                 =joneshf
purescript-free
purescript-http          PureScript HTTP bindings                                   =joneshf
purescript-oboe          PureScript wrapper around oboe.js                          =joneshf
purescript-profunctor    Profunctors for PureScript.                                =mankyki
purescript-runner        Node tool for running Purescript code                      =maciejm
purs-loader              PureScript loader for webpack                              =ethul

[davidchambers]

This is an important point to discuss. Starting with how we'd like to install the PureScript compiler and accompanying tools is a good idea.

I'm interested in adopting PureScript at Plaid. Currently 90% of our code is JavaScript. JavaScript the language is far from ideal, but npm does a good job of managing dependencies. We only depend on node and npm being installed globally; everything else is installed locally in node_modules. My concern is that adopting PureScript will increase the number of global dependencies each developer must keep up to date.

[garyb]

I'm happy this discussion is happening, by the way! There's some older discussion about some of these points on #631.

[jasonkuhrt]

@garyb Sorry for somewhat duplicating that issue. In order to avoid splintering the discussion I'm happy to close this or focus its intent.

For me, the main difference I see, is that we can either work on this problem going forward or backwards. #631 seems to take the approach of going forward. As I've already stated I think another valid alternative is to work backwards. This actually has a name and methodology, Idealized Design, which is explained already and better than I can elsewhere, with example implementations (Flynn); So quoting from them:

https://flynn.io/docs#idealized-design

We incorporate Russell Ackoff’s concept of Idealized Design to our design approach. In short, this means we keep two models of the system in mind. The first and most important is our ideal. This ever evolving concept of Flynn is what we could build if we were starting from nothing. By revisiting this ideal, unconstrained by short-term goals or existing implementations, we can have an accurate concept of exactly what we want. Without this, progress is often based on what you want next, leading to overly complex systems that don’t accurately reflect the latest understanding of the problem.

From this ideal, we can iteratively converge the existing model of the system towards a single cohesive goal, as opposed to many different sometimes competing goals in the form of independent features and fixes.

Knowing what your ideal is not only gives you focus and direction, but it gives you a chance to continuously apply the latest understanding of the problem and design principles. The result should be a simpler system because you’re able to dissolve problems as opposed to just solving problems.

Some might see this as a real-time version of the second-system syndrome. However, it’s actually about the opposite effect. As Rob Pike says, “The better you understand, the pithier you can be.” By continuously moving towards the ideal based on this understanding, you can achieve a more expressive system with less.

http://knowledge.wharton.upenn.edu/article/idealized-design-how-bell-labs-imagined-and-created-the-telephone-system-of-the-future/

[jasonkuhrt]

Some friction:

This does not work:

$ cat **/*.purs | psc --stdin --main=Chapter2 | node
Error in module Math
Cannot import unknown module 'Prelude'

But this does:

$ psc **/*.purs --main=Chapter2 | node

Of course, the later is better but the former was surprising.

[garyb]

What's the error in the first case? There was a sort-of issue with -s a while ago that meant that Prelude is not included when using that option, but I'm not sure if it's still the case.

[jasonkuhrt]

@garyb I edited my comment to include the error, do you see it? Indeed it seems related to Prelude not being there.

[garyb]

Ah ok, yep. It is still the case that when using stdin the Prelude is not included then. Is that still the intended behaviour @paf31?

[joneshf]

npm is unsuitable for distributing PureScript libraries due to the way it handles dependencies, and the fact it is intended specifically for JavaScript packages.

Well the dependencies are only a problem if you use dependencies. If you use peerDependencies deps are installed at the same level, like they are in bower.

The proper way to distribute on npm should be to compile the code to a js file and externs when publishing. This way you don't have sources that need to be recompiled every time, you also are distributing js files, and you have types to go along with it. It becomes transparent that you are even using purescript as a language to someone from the js world.

I think between those two choices, using npm is a viable option.

[joneshf]

Of course, those two changes are worthless unless we also depend on the compiler version in each library. Otherwise you will have some types you cannot use, functions will be missing, or other things.

[garyb]

I think peerDependencies is being deprecated: npm/npm#6565

[joneshf]

Well that's unfortunate, though maybe there's another way around that.

[jasonkuhrt]

Maybe the most useful thing that can come out of this is a succinct document that outlines how to get started, install packages, build, and deploy etc. written as though it were already done. Make it as simple and elegant as possible. And then put it in the back burner while steps to reach it are taken. Revise it in a few weeks.

[paf31]

Here's a thought - what if took the Elm approach and developed tools which could be used in the browser - a PureScript IDE which came with support for standard libraries, running on our Linode box?

It would be a big project, but in the spirit of identifying our ideal system up front, is this the sort of direction which we want to go in? Obviously we would still need to support the grunt/Bower/npm/etc. workflow.

[jasonkuhrt]

@paf31 Something that remains unclear for me is should/will server-side code via typescript ever be a first-class goal? That decision in my mind totally impacts the design of the workflow. I very much imagine that people may well come along and expect that PS can be used like any other AltJS language which are trivial to use on the server in node.

The impact, if nothing else, will come in the flavour of communication and API choices be it in actual functionality or terminology; generally just environmental detection and clear choices for output targets etc.

[jasonkuhrt]

@paf31 If I remember correctly there is discussion about getting PureScript to compile to other backends too? Like the JVM? Something else? Etc.

If so, this would probably have a impact on the ideal workflow too!

[paf31]

I assume you mean /s/typescript/purescript :)

Right now, you can use PureScript on the server if you want to, and people have. The library support is not quite there yet, but it's not impossible, it's just a matter of putting in the work. There are bindings for things like express, for example.

As for other backends, I have always maintained that the compiler architecture should enable people to write backends if they want to, and as easily as possible, but my own focus will be on getting the JS target and associated tools as solid as possible.

[joneshf]

Another option could be a ps specific ecosystem. If we want to get serious about multiple backends, we're going to have to be able to distinguish between a library written specific for language A and another specific for language B. I mean, if you're targeting the browser, you can't use that library with a java or python backend. Whereas if you have an agnostic library (pure ps), then it doesn't matter who uses it.

If we make these distinctions, then the distribution becomes something that is done on a per-library basis, rather than something we have to figure out for everyone. Register it to the ps ecosystem and others (npm, pypi, hackage, etc) if you want, but if you've got an ffi for python, you can't register to the ps ecosystem.

[joneshf]

Here's a thought - what if took the Elm approach and developed tools which could be used in the browser - a PureScript IDE which came with support for standard libraries, running on our Linode box?

I'm unclear what benefit this provides. What goals did you have in mind with this?

[jasonkuhrt]

what if took the Elm approach and developed tools which could be used in the browser - a PureScript IDE which came with support for standard libraries, running on our Linode box?

@paf31 That's fine and well, but maybe not quite what I'm getting at. For instance with Clojure they have the purportedly excellent http://leiningen.org backing much of their workflow experience. I'm pretty sure they offer a tight experience optimized for developer happiness. Maybe the so-called PureScript IDE would be a tool that expedites the build process and can be used within editors to provide live-feedback features etc. where the editor provides the front-end experience and PS is just providing the data analysis and incremental builds/communication in-and-out to the clients etc.

[jasonkuhrt]

For example Flow from Facebook is a server that runs in the background providing incremental analysis.

[jdegoes]

-1 on IDE. Developers want to use whatever tools they are using -- not learn new ones. But yeah, getting, installing, and building needs to get a lot simpler.

Still toying around ideas for a Purescript-�based build / dependency system:

https://gist.github.com/jdegoes/a25ca1cebe226ff469f2

[joneshf]

As far as the npm front, if each library publishes its compiled js and externs for all the things it uses then things should be fine right? Depending on more than one library would just mean that you'd have to remove the duplicates when you go to compile things. Either psc* can be made smarter to do the de-dupe, or ideally another tool would work here for this.

Though, this might cause us to be much more stringent with version changes.

[jasonkuhrt]

@jdegoes I don't have time to dive into this but for your own reference you may be interested to look at the research @sokra is doing into module builder system. Its easily the most advanced fundamentally well thought out system in JavaScript today. But of most interest is the work being done towards WebPack 2 via the Concord Spec https://github.com/webpack/concord. There may be some useful ideas there for you, not sure.

[jasonkuhrt]

-1 on IDE. Developers want to use whatever tools they are using -- not learn new ones.

Agreed, but I wouldn't rule-out tooling that provides services for IDEs to hook into. Every IDE shouldn't have to build PureScript integration from scratch. See my comments above.

[jdegoes]

My own view would be that a build / dependency system should be as minimal as possible, basically supporting only data flow and optionally incremental processing of IO resources -- beyond that, you plug everything else in, e.g. bower support in the above example or git support.

There's still the bootstrapping problem: if you're build system requires you plug-in bower and concord and various other plug-ins before your build file can be executed, then those plug-ins need to live somewhere, which means they need to be described by something, and that something can't be the build file. Maybe it looks like: npm is for building, and you get Purescript compiler and the build system (including plug-ins) via npm dependencies. Then your app is described solely in terms of a Purescript build file, which itself can pull back dependencies from bower, npm, git, or other places as determined by the plug-ins you've chosen for your build.

That still means you need npm before you can start cooking, but if the dependency could be kept to just npm, it wouldn't be the end of the world.

[paf31]

Here are my thoughts (sorry if this comes off as abrupt, I'm short on time today):

• I don't understand why using bower presents any issue. bower has always seemed like a perfect fit to me, and I don't see it as a burden to have to install it.
• I think there is a place for a "Haskell Center for PureScript", but not at the expense of more basic tools.
• I agree that there should be tooling for editors, provided either by the compiler or additional tools.
• I agree that we need to find a clean way to separate pure PS libs from backend specific libs. In my view, this is another good reason to develop very small libraries. We just need a way to tag each library with its type. The bower.json file seems like one possible way to do this.
• stdin support via -s is a legacy feature which I think could possibly be removed. It does not include the Prelude.
• Generally, I don't think these sorts of things should be in the purview of the compiler. I want to compiler to have the absolute minimal support for things like packaging, with tools building support on top. This isn't to say that I don't think these things are important - I think that as a community we should agree on a direction, and take it. However, I think it is important to understand how the chosen direction should be reflected in the architecture. I take the same approach to the compiler as I do to libraries - finer grained responsibilities are a good thing.

[joneshf]

I very much imagine that people may well come along and expect that PS can be used like any other AltJS language which are trivial to use on the server in node.

Yeah, I think this is a point we miss. You just can't do this with ps as it is now. Mostly because it doesn't support nested modules, but also because it needs all the files at once to typecheck things and other issues. So you have to go out of your way to understand the way the compiler works before you can be proficient with it in the js ecosystem.

For instance, it's prohibitively complex to write a transform for browserify, for the reasons above. Whereas coffeeify and friends are fairly straight forward. This isn't a make or break thing, but it's just one example where ps still isn't all the way into the js ecosystem.

You currently just have to be aware of what ps expects in order to function properly, rather than blindly assuming it's like coffescript or something.

[jasonkuhrt]

There seems to be a relative plethora of issues that should just be abstracted into a sane CLI. I don't particularly care where such a tool would live, especially right now, but I've made the issue on this repo because its the entry point into the project.

I don't think throwing raw psc + bower + whatever is going to make any sense, and I challenge you to a corollary that proves otherwise. What I do know is that Node developers love working with npm and Clojure developers have very nice things to say about leiningen, and there is very little friction to getting going with a meteor project. The common theme here is a single abstraction. Right now I don't care to discuss if its a monolith codebase under the hood or an elegant uber-modular 22nd century architecture.

I don't think I've managed to make my point and I'm sorry about that. I realize that my POV, being communication and design focused, probably needs further explanation if the recipient is listening from a deep engineering position.

[joneshf]

stdin support via -s is a legacy feature which I think could possibly be removed. It does not include the Prelude.

I personally like this feature when it works. Lets psc be just another unix tool. But I think discussion should go in a different issue.

finer grained responsibilities are a good thing

I think this is the point being discussed here. When starting out, needing to find/compile multiple tools just to make "hello world" is frustrating and sometimes off putting. When you're already entrenched in ps, the beauty of removable tools is apparent. I greatly appreciate that people can use make to compile ps, just as much as I appreciate that I can leave all this up to gulp. But I'm well deep into the ps ecosystem.

[paf31]

Can you please tell me your objection to using bower? Yes, it adds a dependency, but you don't need to use Bower if you feel strongly about it. People have used git with make successfully for example. You can use npm if you like, but bower so far has been a good fit in my opinion.

I don't think "JS folks are used to npm" is a compelling enough argument to be honest, but maybe I missed something.

[paf31]

@joneshf I feel like, even though I am obviously a very deep into the PS ecosystem as well right now, I also make for an interesting data point here. I have only worked with Node and npm after working on PureScript. I learned bower, grunt, npm, gulp, etc. out of necessity, because we started to standardize on them early in the project's development. It involved a small amount of learning, but it wasn't difficult, and it was definitely a benefit overall IMO.

[jdegoes]

I honestly don't think any of this is the purview of the compiler, except maybe (1) making the compiler available in a versioned dependency manager (such as npm or bower, TBD), and (2) having the compiler be as modular as possible (externs make it somewhat modular now but of course there's more we could do on that front). Everything else needs to live outside the compiler and in separate projects, though this may be as good place as any to discuss what sorts of tools the community needs to focus on.

[jasonkuhrt]

Going to wind down until I have more time to contribute real substance but just going to leave off with the fact that I can't be the only one feeling this:

https://github.com/bodil/pulp

A project that touches on the surface of what I'm trying to get at, created by the very @bodil that presented PS at StrangeLoop this year.

[joneshf]

@paf31 I think it's fair to say you're an outlier in this data set ;).

But I agree with what you say. It's not hard to learn this stuff. It just takes effort. That effort is on top of the rest of the stuff though. Not everyone will have the dedication to get through it all. If there's just one tool to install that does it all, it's easier for everyone. It's why I use yeoman, because I cba to set up a whole project each time.

Also, I don't think the original intent of this issue was that the compiler needs to take on more responsibility. I think we're still not used to the google group existing, and this is the most visible place for a discussion.

[paf31]

@jasonkuhrt Yes, I think pulp is a great project. I would like to see it expanded (and ideally rewritten in PureScript :)

Bear in mind that pulp relies on bower for its dependency tracking though.

[bodil]

OK, as I'm being mentioned and all, you're about to get a dump of my opinions as a consequence:

I like Bower. I'm surprised to find myself liking Bower, as I've used it before for JS projects and found it an unappealing experience. However, given the nature of PS packages, and how they differ structurally from CommonJS, which npm excels at, I've found Bower to be a very good fit for PS projects. I'd like us to keep using it, please.

What I'm trying to achieve with Pulp is a lot like what Leiningen does for Clojure (in fact, Pulp is heavily inspired by Leiningen, UX wise). Basically, to get up and running with Clojure, you install the JVM, you download the Leiningen shell script, and you're good to go. Ideally, with Pulp, you'd install Node, you'd go npm install pulp, and that's it. Of course, that necessitates making psc itself available through the npm repo - basically, npm install purescript needs to be possible. If we can actheve that, though, Pulp can just pull down everything it needs, including Bower (which it does already) and take it from there, just like Leiningen does. The end user wouldn't need to deal with any other tool than Pulp, and of course Node.

I'm also trying to keep Pulp simple - it shouldn't be more than a wrapper around psc et al, psci and bower that knows how to invoke them correctly for your projects. If you need build orchestration beyond taking some PS and producing some JS, there are plenty of tools available to take over where Pulp leaves off, including npm (which I've found sufficient for my own projects so far) and make. And if you really need something more complex, Grunt is still available and can deal with Bower based projects just as well as Pulp can.

Pulp might benefit from a plugin system like Leiningen's, but I'm a bit worried that might turn it into a Grunt style task runner rather than a user friendly wrapper for the basic build tools. Leiningen seems to have managed, though.

I've found that having a simple packaged IDE can be great as a teaching tool, and just to help people get a taste of the language. I did something similar for Clojure in a previous life, which worked out very well: https://github.com/bodil/catnip Obviously, these things aren't suited for serious development, but they're great for adoption and training, and shouldn't be discounted just because Emacs (or your favourite pretender to the editor throne) is obviously the superior choice.

Speaking of editors, please look to Idris: one of its core pieces of tooling is a lightweight API for IDE-ish features that can be easily plugged into any editor. Even something like ghc-mod and hlint would be a really good start. The PS editor experience right now is rather uninspiring next to Haskell and Idris, and even JS.

[jasonkuhrt]

@bodil Thanks for your thoughts!

[jdegoes]

Bower's indeed the best dependency management system I've run across, allowing one to cleanly state: I depend on this version of this project from this URI. Couldn't be simpler than that. It's the the combination of tools that throws off people new to the ecosystem, and that's where a tool like pulp can really shine.

[jasonkuhrt]

bower was designed to be built on top of. It can be successfully paired with https://github.com/broccolijs/broccoli or http://webpack.github.io/ etc. I don't think bower should really be the debate here. Again that's thinking forward rather than backwards. If we have an ideal design we can simply ask if bower satisfies it or not, and more.

-- edit
And pardon if I dragged it directly into the hotseat

[AKST]

Hey so, @garyb suggested I mentioned some issues I've ran into with my first 24 hours in Purescript over here. First off I realise the language is still being actively developed so some of the stuff I guess should be expected.

I got past installing the compiler, but I already had cabal installed & I knew how to use sandboxes, and all that node stuff. Anyways the main struggle I had was getting libraries to work, the most confusing one for me was purescript-virtual-dom. It was using some require statements here and there, and I tried to replace the require statements with expressions pointing to the exact parts of the virtual-dom library, but I ended up posting an issue on the repo (I now have an answer)

What would have gone along way for me to build this project would have being told to use something like pulp off the bat (like before I even started installing libraries), but also providing a simple build script with the library example.

I also tried a bunch of different libraries each with their own struggles

• purescript-jquery, the api was confusing at times for some things, and didn't actually give much feedback when I did certain things wrong (but that's jquery I guess), I also found some of the types kind of opaque but whatever (again jquery I guess). Issue here
• purescript-simple-dom, doesn't actually have a method for creating dom elements, I posted a question about this on the repo, but I found that surprising
• purescript-react, I had a hard time trying to get the nightly version of react to install through bower, maybe an example in the readme would help?

I really just wanted to build a UI of some sorts, so I tried a bunch of different libraries for it and still don't really know if there's a go to suggested library for this kind of thing.

Edit: One last thing, I will say so far people have been pretty helpful with responding to issues (so thanks for that), and I think the fact this language exists is awesome

[paf31]

You might like to look at purescript-thermite, which is another set of bindings to React. Where purescript-react is low level, thermite is high-level, simpler (in my opinion) and more functionally-oriented, but at the expense of some features.

[AKST]

Thanks I'll be sure to check that out
On Sun, 1 Mar 2015 at 3:59 pm, Phil Freeman notifications@github.com
wrote:

You might like to look at purescript-thermite, which is another set of
bindings to React. Where purescript-react is low level, thermite is
high-level, simpler (in my opinion) and more functionally-oriented, but at
the expense of some features.

—
Reply to this email directly or view it on GitHub
#749 (comment)
.

[garyb]

@paf31 do you think it might be worth revising the book to use pulp for the exercises? It would certainly be a much quicker path to getting started. Could just mention as a side note that plugins for Gulp, Grunt, etc. are also available when the need arises for more complex builds.

Also the point in there about only making binaries for major versions isn't quite true anymore either, certainly not since the 0.6.x release cycle.

[jasonkuhrt]

Echo's my feelings a bit http://blog.jenkster.com/2015/02/a-brief-and-partial-review-of-haskell-in-the-browser.html

There are a few downsides for me that eventually stacked up too high. Tooling's a bit of a pain. (You'll need Node. And Grunt. And Bower. Wait, are we actually building a JavaScript project?)
[...]
Bonus Tip: If you're playing with PureScript, Take a look at Bodil Stokke's Pulp for your building needs. That worked well for me.

[alexchandel]

I went with brew install purescript and haven't looked back. Cabal is better suited for build management, not package management.

@garyb purescript.org's download page should have a Package Manager section below Binaries, for brew install purescript and Linux variants (if any). Being installable via Homebrew is a major win for OS X development.

[joneshf]

Cabal is better suited for build management, not package management.

Totally agree, it's even their mantra.

@garyb purescript.org's download page should have a Package Manager section below Binaries, for brew install purescript and Linux variants (if any). Being installable via Homebrew is a major win for OS X development.

You should submit a PR around here: https://github.com/purescript/purescript.github.io/blob/master/download/index.html#L41

There are two packages in the AUR that i'm aware of: https://aur.archlinux.org/packages/?O=0&K=purescript.

Nix has it. You can search for it here: https://nixos.org/nixos/packages.html.

I don't really follow the other distros though.

[alexchandel]

purescript/purescript.github.io#18 merged. A maintainer should upload the Windows binary to chocolatey.

As for a getting started vision, purescript.org probably needs a Packages tab with text similar to purescript/purescript.github.io#17 and a link to Pursuit

[paf31]

I think npm install purescript and npm install pulp are simple enough that I can close this now.

[GetContented]

One way to "solve" this might be to do what elm does... that is, make "elm" just a catchall command for all sub-commands,... and if bower is just an alias - ie the subcommand for "ps-package", all good :)