Optimise the installation process

[cjbell]

From @stueccles install experience, we need to make this easier to get up and running (especially with Rails).

• Bundle underscore / eventable into the Gem file.

I think this poses a bigger question though; should we have Sir Trevor Rails purely as a set of helpers for SirTrevor, rather than including any assets?

It would be great to get your thoughts @ninjabiscuit @stompydan

[arbarlow]

Sir trevor could just depend on the underscore ruby gem and then make an eventable gem?

The rendering of blocks will never be too easy however

[cjbell]

I'm not sure. I definitely prefer to see Bower managing JS dependencies rather than bastardising Gems.

[arbarlow]

You can't expect Rails devs to use Bower, when the asset pipeline is the default configuration. I'm not a fan of gems for js files, but it might solve this problem? Or you can bundle underscore/eventable too

[andflett]

IMO it should be as simple as the original sedit gem, i.e. the only steps you should have to take are:

1. Include Gem
2. Use custom input form field
3. Call a render method as you would simple_format

There should be zero thinking involved, and even less consideration of dependencies required.

Sent from my iPhone

On 23 Jul 2013, at 14:27, Alex Barlow notifications@github.com wrote:

Sir trevor could just depend on the underscore ruby gem and then make an eventable gem?

The rendering of blocks will never be too easy however

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

[cjbell]

Even without Bower, it would simply be a case of them sourcing the JS and including it in their application. I think us bundling dependencies is bad and is something I want to avoid as it means we have to keep the versions up to date etc etc.

Personally, I'm all for the idea of keeping this repo as a set of helpers and views for ST. Maybe we could even add a rake task that grabs the latest versions of underscore / eventable / sir-trevor and adds them into your vendor/assets/javascripts directory and even include them in your sprockets file. Or is that overkill?

[arbarlow]

I dunno, I think bundling the dependencies is fine. Thats what this is, a Rails Gem that helps you install Sit Trevor into Rails. If it doesn't do that, then its just a javascript library, as writing the rendering is trivial.

Rails should be convention over configuration, no?

[andflett]

Absolutely, favour usability over technical architecture. Also, we'd need to lock down our dependency versions anyway.

One line install, then write a wiki article for getting it things running with the pure JS version if there is a dependency conflict - not sure eventable and underscore are widely enough used to be of major concern."

Sent from my iPhone

On 23 Jul 2013, at 14:44, Alex Barlow notifications@github.com wrote:

I dunno, I think bundling the dependencies is fine. Thats what this is, a Rails Gem that helps you install Sit Trevor into Rails. If it doesn't do that, then its just a javascript library, as writing the rendering is trivial.

Rails should be convention over configuration, no?

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

[stueccles]

I should be simple enough I can do it. See Sprinz's description of stupid easy. Also Sprinz, shouldn't you be doing daddy stuff right now....

On 23 July 2013 14:44, Alex Barlow notifications@github.com wrote:

I dunno, I think bundling the dependencies is fine. Thats what this is, a Rails Gem that helps you install Sit Trevor into Rails. If it doesn't do that, then its just a javascript library, as writing the rendering is trivial.

Rails should be convention over configuration, no?

— Reply to this email directly or view it on GitHubhttps://github.com/madebymany/sir-trevor-rails/issues/8#issuecomment-21414579 .

Made By Many Ltd Diespeker Wharf 38 Graham Street London N1 8JX

@stueccles / +44 793 955 6523

[andflett]

Sorry, get kicked out at lunch, visiting hours, get bored!

Sent from my iPhone

On 23 Jul 2013, at 14:49, Stuart Eccles notifications@github.com wrote:

I should be simple enough I can do it. See Sprinz's description of stupid easy. Also Sprinz, shouldn't you be doing daddy stuff right now....

On 23 July 2013 14:44, Alex Barlow notifications@github.com wrote:

I dunno, I think bundling the dependencies is fine. Thats what this is, a Rails Gem that helps you install Sit Trevor into Rails. If it doesn't do that, then its just a javascript library, as writing the rendering is trivial.

Rails should be convention over configuration, no?

— Reply to this email directly or view it on GitHubhttps://github.com/madebymany/sir-trevor-rails/issues/8#issuecomment-21414579 .

Made By Many Ltd Diespeker Wharf 38 Graham Street London N1 8JX

@stueccles / +44 793 955 6523 — Reply to this email directly or view it on GitHub.

[raffij]

Include underscore.js as is. Allow me to override underscore with my own version, so don't use crazy new functions as soon as they are released. Give the pros an option in config to stop asset pipeline including underscore.js, or tell them to add an empty underscore.js in the correct place to override for now.

[dwb]

I don't see anything wrong with requiring bower for cleverness, or leaving you to get the (documented) dependencies manually. Bundling dependencies in with the gem is just a messy halfway house. Bower isn't hard and the exact (short) setup can go in the documentation here too.

Here's a compromise: one gem with bundled dependencies, and then one without – for when you realise that all the JS libraries that are bundled over your many gems are all clashing and you need a proper package manager. You could build them off the same repo. If we're only having one, though, I definitely vote for no dependency bundling.

[ninjabiscuit]

I really think dependency bundling will mutate into greater maintenance issues down the line. I agree that overly complicated installations are a ball ache (have you ever tried to install tinyMCE from the gem shudder) but devs are used to managing front end dependencies. Bower (and other package managers) came along to make this easier, but dev's that haven't integrated it into their process yet will either use other tools for managing deps or will be quite used to managing them their selves. The issue is not that you should be able to install ST with one line, but that the process should be as fuss free as possible and documented from beginning to end at the top of the readme.

Moving the assets out of the gem seems like an appropriate separation of concerns. :+1: for @cjbell88's comment about making this a separate repo for rails specific helpers and generators.

[arbarlow]

I'm not sure how specific dependency bundling could lead to any maintenance issues at all, in fact the opposite? Have we had this before out of interest? I just tried to use sir trevor and upon downloading the latest underscore.js and putting them together, found it didn't work..

Gems that bundle javascript are providing nothing more than a convenience file, as you can choose to use the bundled underscore, or you own..

//= require sir-trevor/underscore

or

//= require mylibs/underscore

Dependencies aside, even if we don't include them, I do think using Bower isn't a great idea, whilst a nice tool. It's very specific and has nothing to with Rails, and also requires Node and NPM, potentially making stuff even more difficult.

We can link to specific versions of underscore and eventable via their github tags? A rake task or something to fetch a specific versions isn't perhaps too bad. I could see that getting messy however though, since you would have to remember to update the rake task on release etc?

[stueccles]

I'm in favour of bundling and using Barlow's //= require sir-trevor/underscore

For lots of devs you don't necessarily want to install Node and NPM and Bower just to try out something. Its another thing to learn and another thing to manage and yet adds nothing to sir_trev itself.

I prefer simple usability over architectural pureness in this sense.

I like my gems to plug-play-and work first time. Remember it has to be simple enough I can do it....

On 24 July 2013 15:45, Alex Barlow notifications@github.com wrote:

I'm not sure how specific dependency bundling could lead to any maintenance issues at all, in fact the opposite? Have we had this before out of interest? I just tried to use sir trevor and upon downloading the latest underscore.js and putting them together, found it didn't work..

Gems that bundle javascript are providing nothing more than a convenience file, as you can choose to use the bundled underscore, or you own..

//= require sir-trevor/underscore

or

//= require mylibs/underscore

Dependencies aside, even if we don't include them, I do think using Bower isn't a great idea, whilst a nice tool. It's very specific and has nothing to with Rails, and also requires Node and NPM, potentially making stuff even more difficult.

We can link to specific versions of underscore and eventable via their github tags? A rake task or something to fetch a specific versions isn't perhaps too bad. I could see that getting messy however though, since you would have to remember to update the rake task on release etc?

— Reply to this email directly or view it on GitHubhttps://github.com/madebymany/sir-trevor-rails/issues/8#issuecomment-21489762 .

Made By Many Ltd Diespeker Wharf 38 Graham Street London N1 8JX

@stueccles / +44 793 955 6523

[ninjabiscuit]

The maintenance overhead relates to having to keep up to date with new versions of dependencies as they are released. @arbarlow - your problem could have been mitigated by proper documentation that specifies compatible versions.

WRT Bower, Dan just made the excellent point that while bower is specific and has nothing to do with rails, ruby gems are specific and have nothing to do with javascript.

Agreed that Bower is great for the devs that use it and a hurdle for those that don't. But those that don't can go ahead and copy the deps from the github repo. This step can be made clear in the docs. In that way, you still don't need npm or node or bower and it's simple enough that @stueccles can do it ;)

[stueccles]

I am talking about just bundling for Sir-Trev Rails not the JS project. Then it should be rails specific therefore bundler.

On 24 July 2013 16:08, ninjabiscuit notifications@github.com wrote:

The maintenance overhead relates to having to keep up to date with new versions of dependencies as they are released. @arbarlowhttps://github.com/arbarlow- your problem could have been mitigated by proper documentation that specifies compatible versions.

WRT Bower, Dan just made the excellent point that while bower is specific and has nothing to do with rails, bundler is specific and has nothing to do with javascript.

Agreed that Bower is great for the devs that use it and a hurdle for those that don't. But those that don't can go ahead and copy the deps from the github repo. This step can be made clear in the docs. In that way, you still don't need npm or node or bower and it's simple enough that @stueccles https://github.com/stueccles can do it ;)

— Reply to this email directly or view it on GitHubhttps://github.com/madebymany/sir-trevor-rails/issues/8#issuecomment-21491482 .

Made By Many Ltd Diespeker Wharf 38 Graham Street London N1 8JX

@stueccles / +44 793 955 6523

[higgis]

The difference with Bundler is that everyone trying sir-trevor-rails will definitely have bundler installed and know about it, whereas only a subset of those people will have Bower. There's a kryptonite factor to installing some installer to install things, especially when its side effects are not known.

Bear in mind that if we're going to PR this at media companies and so on, they're probably going to be prevented from using this if it requires node.js and that's not on their list of approved tools, especially if it's required for deployment.

They're conceptually equal, but one is more equal than the other for Rails devs.

On Wednesday, 24 July 2013 at 16:08, ninjabiscuit wrote:

The maintenance overhead relates to having to keep up to date with new versions of dependencies as they are released. @arbarlow (https://github.com/arbarlow) - your problem could have been mitigated by proper documentation that specifies compatible versions.
WRT Bower, Dan just made the excellent point that while bower is specific and has nothing to do with rails, bundler is specific and has nothing to do with javascript. Agreed that Bower is great for the devs that use it and a hurdle for those that don't. But those that don't can go ahead and copy the deps from the github repo. This step can be made clear in the docs. In that way, you still don't need npm or node or bower and it's simple enough that @stueccles (https://github.com/stueccles) can do it ;)

— Reply to this email directly or view it on GitHub (https://github.com/madebymany/sir-trevor-rails/issues/8#issuecomment-21491482).

[ninjabiscuit]

In each of my previous comments I've tried to make it clear that I think there should be two routes to installing the deps. One with bower and one which is manual. The option of using bower does not preclude the option of installing deps manually. We're talking about two javascript libraries here. Thats not rocket science. The node/bower/npm overhead is completely optional in this scenario.

[cjbell]

NINJA SMASH!!!

[cjbell]

How about this for a plan:

• Remove all assets currently in ST-Rails
• Re-write the documentation with a Bower install process AND a manual asset install process
• Include the (awesome) changes @dwb has made to Sir Trevor Rails on ITV and make the Gem a set of helpers

:+1: or :-1:

[dwb]

If they can't use bower, then they can just pull down a couple of .js files. And if they can't do that, well, I don't really know. This isn't an end-user application, it's a library for developers to integrate. We've suggested a super-easy method, or a not-very-much-harder-at-all method that keeps us from dealing with dependencies ourselves.

If we end up bundling the dependencies in the project I don't think it'll be terrible or anything, I just think it's a weird concession that will end up being more trouble than potential users of this gem doing two minutes more work.

So :thumbsup:!

[ninjabiscuit]

:+1:

[jcc8]

Bounty on this issue here if anyone wants to pledge/take on the issue: https://www.catincan.com/bounty/optimise-installation-process-issue-8-madebymany-sir-trevor-rails-github

[MichaelSp]

Still open?! :disappointed: You could use www.rails-assets.org There's a sir-trevor gem already. And they deal with the dependencies. Feels more rail-ish to me.