More Cowbell

"How do you use Javascript included in a Desert plugin?"

I've just created an initial, proof-of-concept implementation of a Desert 'meta-plugin' to add this functionality:

http://github.com/pivotal/desert_assets

Checkout the readme to see how to use desert_assets to allow your very own desert plugin to provide assets (javascript only for now) without needing to run a script to copy files.

To Dos:

• Add specs for the JavascriptsController
• Test drive StylesheetsController and ImagesController
• Add asset packager handling to include the resultant javascript and css files in all.js and all.css, respectively
• (maybe) Allow for files to be non-erb and located in the public hierarchy

@Corey,

Why didn't you just fork desert instead of creating a separate plugin? That would make it easier to roll this functionality back into desert if it works out.

Not criticizing, there may be good reasons, I'm just very (painfully) aware lately of the downsides of creating new gems/plugins rather than just enhancing existing ones.

-- Chad

@Chad,

I thought about that, but figured it would be nice for this functionality to be optional.

I'm interested in hearing more about the painful downsides you've experienced with plugins.

@corey,

Well, I won't mention names (well, maybe I will at the end), but it boils down the the "Not Invented Here" syndrome (even when it is something else that WAS invented here).

When you have a completely separate project, that implies separate codebases, separate tests, separate deployment, separate installation instructions, etc. etc.

For something like this that seems so closely tied to the goals and purpose of Desert, it makes sense for it to be part of desert.

If you want to make it optional, that can mean (at least) two things. You might want to make it optional because it is not fully-baked yet, and needs more testing/improvement/maturity. Or, you might want to make it optional because it is fully-baked, but not everyone will want it.

In the former (not fully baked) case, I'd still say that a github fork is the best way to manage this. People who are willing to live on the bleeding edge should have no problem knowing when and how to use a forked branch with new features, and the only thing you need to ensure is that your fork stays up-to-date with the master branch (which is easy with the github gem).

In the latter (fully baked but not everyone wants) case, I'd say that it still belongs as part of the main package if it is as very similar and related functionality (as this seems to be). And, to get to this point, you probably had to go through at least some period of forked not-fully-bakedness before it was merged into trunk, unless you did the changed directly in master (which is also fine if you don't break stuff).

The case where you DO want a separate gem/plugin is where the functionality is truly unrelated, or a definite subset of functionality that many people don't want. For example, I started the selenium-rails gem which depends on the Selenium (-ruby) gem, because not everyone who uses Ruby uses rails. In the case of the Polonium gem, this depends on the Selenium gem, but contains much generic rails-independent functionality (rspec support, auto-starting selenium and app servers, etc) that would have been much better off as a direct contribution to the Selenium gem, and a little bit of rails-specific functionality that would be better off in a specific selenium-rails gem. We've (the owners of all these gems) have come to that collective conclusion, and are sorting it out. However, it would have been better to go the route of improving the Selenium in the first place, rather than coming up with something separate like the Polonium gem that contains mostly related enhancements that many or most users of the Polonium gem would find useful.

Update on the capistrano / net-ssh errors when ssh-ing to localhost on linux. I fixed this by upgrading to the latest capistrano (2.5.0) + capistrano-ext (2.1.0) + net-ssh (2.0.4).

Apparently there was some conflict with ssh-agent, gnome, seahorse, seahorse-agent, ubuntu, etc when capistrano and net-ssh tried to connect to localhost - even though there was a id_rsa key properly set up and added to ~/.ssh/authorized_keys, and no-password ssh to localhost worked manually.

If you are wondering, we are deploying to localhost because we test our capistrano deploy process under continuous integration by doing a deploy to a 'local' localhost environment as part of each CI build.

Original error message for future googlers:

connection failed for: localhost (Errno::ENOENT: No such file or directory - /tmp/ssh-EShnwF6579/agent.6579)

-- Chad