Closed glenngillen closed 9 years ago
Wicked, thanks for this. I've not looked at it yet (Valentine's weekend is proving to be a busy one) but I've pencilled it in for first thing Monday morning.
That looks like a bit of a Herculean effort. I agree with all your bullet points, and the namespace observation. Thanks v. much for investing the time and fighting through it.
I woke up this morning thinking "there must have been an easy way to make this Rakefile before bundler". Google has lead me here: http://effectif.com/ruby/manor/gem-this
My words, and (if I recall correctly) your photos!
I wondered whether we should use gem-this
and just check the result in to templates/plugins
, so I ran it. The Rakefile
looks like a reasonable starting point but contains a bunch of stuff that I suspect we don't need.
Then I found an article by Yehuda that contains (essentially) this snippet:
task :build do
system "gem build mygem.gemspec"
end
task :release => :build do
system "gem push mygem-x.y.z"
end
I may be having another bout of early-morning-brain-fail, but am wondering whether we can just use that, replacing the name/version of the gem with Erb when nesta plugin:create
gets run. What do you think?
I've been thinking about this some more, and perusing the tasks Bundler provides some more. There's definitely some useful stuff in there (e.g. tagging, and checking that everything is committed).
I'm wondering whether we could move all the code that implements the tasks into a Rakefile
in templates/plugins
and drop GemHelper
. Shall I take a run at it?
It'd be easy enough to move it all into the Rakefile
but I think having it in a module carries two benefits:
Rakefile
The whole CLI API around gem
and git
seem stable enough for that last point to not be super valuable. Or are we just setting ourselves up for inevitable pain?
Does it need testing? I'm not sure how/why it'd need to change in future in a manner that might break existing functionality (where "not sure" means I'm not sure, rather than I've researched it hard and understood it in depth).
Which gem are you talking about updating? Bundler? If so, I suspect we're unlikely to want to do that as it's likely to get refactored in ways that we don't care about. Only if the general interface to rubygems itself changes (in a manner that isn't encapsulated by the gem foo
commands) are we likely to need to ever touch this again.
Famous last words… ;-)
Yeah it's totally the "famous last words" problem. It seems like a lot of effort and complexity to address anxiety rather than a real and likely breakage.
I'll try make some time to replace it today.
Alright, changes made. Commits squashed. Branch force pushed.
Care to take a look?
Lovely work. I'll pull your commit into my topic branch and get this thing wrapped up…
I cherry picked your commit into my plugin-templates branch, then made a few tweaks. It's all looking good, and I've successfully made a test plugin with it.
All I need to do now is update CHANGES and we'll have a new release of Nesta… :-)
:+1: :beers: :tada:
Thanks!
Opening this PR to start a discussion on direction and implementation, I don't think this is ready to merge yet.
As we've discussed out of band, this missing piece to stop us being tied to a specific version of Bundler is to reproduce the
Rakefile
it generates for managing gem releases. It wasn't as straightforward as I'd expected given theRakefile
itself calls into Bundler methods, and so those needed to be reproduced locally. I initially copied both the specs and implementation wholesale but ran into some problems because the specs actually call out togit
andgem
when they run. Here's a rough collection of notes I made about potentially significant changes to the specs:git
andgem
)gem build
, capture and pass on any error output, and then move the.gem
file intopkg/
when successful. The last bit seems like the only useful bit to test, the rest should be taking as a contract with thegem
. Thoughts?They're now passing. That said there is probably some room for improving the implementation, at the very least I'm not comfortable with the namespace I've dropped everything into. I'll need to take a break and come back to this with fresh eyes to have some objectivity on what to fix.
Let me know if you've any suggestions, or if we should just kill it :fire: