-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimise the installation process #8
Comments
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 |
I'm not sure. I definitely prefer to see Bower managing JS dependencies rather than bastardising Gems. |
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 |
IMO it should be as simple as the original sedit gem, i.e. the only steps you should have to take are:
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:
|
Even without Bower, it would simply be a case of them sourcing the JS and including it in their application. 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 |
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? |
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 should be simple enough I can do it. See Sprinz's description of stupid On 23 July 2013 14:44, Alex Barlow notifications@github.com wrote:
Made By Many Ltd @stueccles / +44 793 955 6523 |
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:
|
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. |
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. |
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. 👍 for @cjbell88's comment about making this a separate repo for rails specific helpers and generators. |
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..
or
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? |
I'm in favour of bundling and using Barlow's //= require For lots of devs you don't necessarily want to install Node and NPM and 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 On 24 July 2013 15:45, Alex Barlow notifications@github.com wrote:
Made By Many Ltd @stueccles / +44 793 955 6523 |
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 ;) |
I am talking about just bundling for Sir-Trev Rails not the JS project. On 24 July 2013 16:08, ninjabiscuit notifications@github.com wrote:
Made By Many Ltd @stueccles / +44 793 955 6523 |
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:
|
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. |
How about this for a plan:
👍 or 👎 |
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 👍! |
👍 |
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 |
Still open?! 😞 |
From @stueccles install experience, we need to make this easier to get up and running (especially with Rails).
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
The text was updated successfully, but these errors were encountered: