ddfreyne changed the topic of #nanoc to: 3.6.4 (may 29th) | web http://nanoc.ws/ | repo http://bit.ly/XE6e3G | issues http://bit.ly/VfXaSV | forum http://ho.io/n-discuss | irclog http://irclog.whitequark.org/nanoc
bghost has joined #nanoc
bghost has quit [Quit: leaving]
naturehack has joined #nanoc
<naturehack> any suggestions for a simple lightbox for html?
naturehack has quit [Quit: Leaving]
ruralhack has joined #nanoc
<ruralhack> haha, this id banned from freenode years and years ago. it's good again. my first freenode id. cool
<ruralhack> lightbox suggestions?/
ruralhack has left #nanoc ["Leaving"]
skroon has quit [Read error: Connection reset by peer]
skroon has joined #nanoc
alerante has quit [Remote host closed the connection]
darix has quit [Ping timeout: 264 seconds]
darix has joined #nanoc
darix has joined #nanoc
alerante has joined #nanoc
guardian has quit [Read error: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number]
guardian has joined #nanoc
cDlm has quit [Quit: cDlm]
louquillio has quit [Remote host closed the connection]
skroon_ has joined #nanoc
skroon has quit [Ping timeout: 264 seconds]
cDlm has joined #nanoc
<bobthecow> skroon_: i've got ~2500 pages in one of my nanoc sites.
<ddfreyne> I really want to create a nanoc-core repo. I'm sick of automated tests failing
<bobthecow> treat plugins the way guard does.
<bobthecow> split every single one of 'em out into `nanoc-foo` gems
<bobthecow> version 'em separately.
cDlm has quit [Quit: cDlm]
<ddfreyne> bobthecow: Yeah, that is what I was thinking. How do you handle versioning? I'd like to stick with semantic versioning for plugins, so that it starts as MAJOR.0.0 with MAJOR being the nanoc major version. 3.0.0 would be the version number for new plugins
<bobthecow> thanks to semver, you can make them depend on major versions.
<bobthecow> no, the plugins would start with 1
<bobthecow> just like if you were to make a guard plugin.
<ddfreyne> So, entirely independent from nanoc's versioning scheme?
<bobthecow> nanoc-handlebars v1.0.0 depends on nanoc ~3.x
<bobthecow> yeah.
<bobthecow> think about it from my perspective.
<bobthecow> i'm going to make `nanoc-bacon` which is a bacon-generating plugin for nanoc.
<ddfreyne> Yeah, I'm actually in favour of that
<bobthecow> i'm not going to start on v3, am i?
<bobthecow> so why should yours?
<bobthecow> there's already an awesome dependency declaration and management system built in to rubygems.
<ddfreyne> Agreed
<bobthecow> why fake one that can't even be enforced via version numbers?
<ddfreyne> bobthecow: The only reason why I would start at 3 is so that people can deduce from that that it can be used with nanoc 3.x
<bobthecow> meh.
<bobthecow> most people will just make a gemfile with 'nanoc', 'nanoc-handlebars', 'nanoc-bacon' in it and let rubygems take care of it'
<bobthecow> *maybe* they'll specify a version for the nanoc gem.
<bobthecow> but why specify versions for the plugins at all? just take whatever matches the nanoc version.
<bobthecow> and let rubygems handle that bit, because it actually knows, rather than doing arbitrary mental pattern matching on gem versions.
<ddfreyne> bobthecow: Would you consider nanoc-cli to be separate? I want to pull them apart even more in nanoc 4.0, so that it is easy (easier) to build a web frontent, so there coudl be nanoc-cli and nanoc-web-gui, maybe nanoc-cocoa-gui, whatever
<bobthecow> if you're going to split things like that out, it would probably make sense for the nanoc gem to depend on the cli gem.
<ddfreyne> bobthecow: Sorry, now following you there. What do you mean with "why specify versions for the plugins at all"?
<ddfreyne> Yeah, there would be a nanoc gem that depends on nanoc-core and nanoc-cli
<bobthecow> that's my project's gemfile.
<bobthecow> notice how many versions i explicitly require?
<bobthecow> one, and that's because libv8 is really really dumb.
<ddfreyne> bobthecow: Oh yeah, that makes sense. Even with the plugins split out, it would still work that way
<bobthecow> there's no reason for someone to manually specify what plugin version they're using, so it doesn't matter what plugin version numbers look like.
<ddfreyne> bobthecow: what about... nanoc-deployers, nanoc-checks as gems? They're not core.
<bobthecow> let rubygems decide what version.
<ddfreyne> (part of those gems would be cli commands too)
<bobthecow> what dependencies are killing you?
<bobthecow> i wouldn't go subproject crazy, just for the sake of other people figuring out what's going on with the codebase.
<bobthecow> take resque.
<bobthecow> it has resque, and resque-web
<ddfreyne> These could all be repositories, possibly gems.
<ddfreyne> I like the idea of putting them in repositories, and I like the idea of putting them in gems. Gems are nice because they can be released independently from the nanoc release cycle
<ddfreyne> (which is something people have complained about before, because the nanoc release cycle is slow)
<bobthecow> maybe have a nanoc-filters meta-gem that just installs all of 'em
<bobthecow> for people not using a gemfile :0
<bobthecow> :)
<bobthecow> nanoc-whole-meal-deal depends on all of nanoc.
<ddfreyne> They should use a Gemfile!
<ddfreyne> nanoc-full maybe?
<ddfreyne> nanoc-bloat? :D
<bobthecow> just for the sake of non-dev, non-ruby, non-nanoc users.
<bobthecow> what's the quickest way to get someone using it?
<bobthecow> if it's "open a file, copy and paste these fourteen lines into it, then run bundle install"
<bobthecow> ... thats a bit intense.
<ddfreyne> Yeah, true.
<bobthecow> so i feel like there should be a default stack.
<bobthecow> maybe installing nanoc installs the default stack.
<ddfreyne> What would be a good name for that? -full? -bloat? -all? -buffet?
<ddfreyne> I wouldn't let the nanoc gem depend on all that. It's only good for backwards compatibility.
<ddfreyne> -powerpack?
<bobthecow> no, i wouldn't make it depend on everything.
<bobthecow> i'd make it depend on a default stack though.
<bobthecow> erb, markdown, and a couple of helpers?
<bobthecow> i'd do -all for the multipack.
<ddfreyne> nanoc could depend on some standard stuff. ERB is bundled with Ruby so it makes sense to let nanoc depend on that
<bobthecow> i think it makes sense to have an opinionated "this is the core nanoc stack" that the nanoc gem depends on.
<bobthecow> people who want to build their own stack could use nanoc-core, nanoc-cli, etc
<ddfreyne> bobthecow: But then we have something opinionated, and I want to avoid that
<bobthecow> but `gem install nanoc` should get me something useful.
<bobthecow> i don't think you should.
<bobthecow> the nanoc gem can be opinionated.
<ddfreyne> bobthecow: nanoc-powerpack depending on everything is good, though
<ddfreyne> Hmmm.
<ddfreyne> What should it include, you think?
<bobthecow> as i see it, you provide plumbing for people who want crazy control.
<bobthecow> nanoc-core, no cli, plus my own nanoc-crazy-web
<bobthecow> or whatever.
<ddfreyne> Definitely ERB. Probably markdown, but which implementation? I like kramdown, because it is pure Ruby.
<bobthecow> think about rails' stack.
<ddfreyne> In any case, everything in the default stack should be pure Ruby. Do you agree?
<bobthecow> yes.
<bobthecow> there are two basic rails stacks.
<bobthecow> if you just do 'gem install rails' you'll get the default stack.
<bobthecow> but you can build yourself the alt-stack (someone called it the prime stack a while back?) if you want to.
<bobthecow> and a decent chunk of people do.
<ddfreyne> haml and sass, possibly
<bobthecow> but if you said "we don't want to make decisions for you" and make everyone choose their stack every time, that would be kinda crappy. would make diving in a lot harder :)
<ddfreyne> bobthecow: I agree
<ddfreyne> bobthecow: erb, kramdown, haml, sass. What do you think?
<ddfreyne> relativize_paths possibly. It's nice!
<bobthecow> yeah.
<bobthecow> that was going to be my other suggestion.
<bobthecow> but that depends on libxml, right?
<bobthecow> is that ever problematic?
<ddfreyne> Nope
<ddfreyne> Oh wait, I was going to rewrite it
<ddfreyne> Yeah... nevermind
<ddfreyne> What helpers should nanoc depend on?
<ddfreyne> I find that most nanoc helpers are a bit low-quality.
<bobthecow> but they should be improved :)
<bobthecow> seems like everyone uses blogging and link_to?
<ddfreyne> rendering, too
<bobthecow> yeah.
<bobthecow> i use capturing in every site i build that's non-trivial.
<ddfreyne> html_escape, link_to, blogging, tagging, rendering. Good?
<ddfreyne> I need to rethink capturing...
<ddfreyne> bobthecow: Also, keep in mind that once something is part of nanoc, it cannot be removed again
<ddfreyne> So I'd rather keep the list as small as possible, with the option to extend it later
<bobthecow> yeah.
<bobthecow> i figure the default stack should be able to compile the nanoc skeleton site, and a generic "i just ported my blog from jekyll / octopress" site.
LBo has quit [Quit: Oogjes dicht en snaveltjes toe...]
<ddfreyne> bobthecow: https://gist.github.com/ddfreyne/6206130 you happy with this?
<bobthecow> for the latter, i mean have enough filters and helpers to accomplish said task, not be able to compile a jekyll site without changes.
<ddfreyne> yep
<bobthecow> i wouldn't make nanoc-powerpack the one that builds the default stack.
<bobthecow> i would make that nanoc.
<bobthecow> because you've already got nanoc-core
<bobthecow> if you want the "no dependencies" version
<ddfreyne> bobthecow: oh yeah, my mistake. powerpack should still depend on everything, then?
<bobthecow> or at least a significant subset of them?
<ddfreyne> Everything :D
<bobthecow> would make sense for it to depend on all official filters and helpers.
<bobthecow> oh, should nanoc depend on nanoc-check and nanoc-deploy?
<ddfreyne> yes
<ddfreyne> Also, check and deploy could be more granular. nanoc-check-html, nanoc-check-css, ...
<ddfreyne> That makes sense too, so that people can write their own checksand deployers easily
<bobthecow> i'd prolly just keep the default checks in nanoc-check
<bobthecow> then other people can write nanoc-check-foo
<bobthecow> it's not like the filters where there are a bajillion defaults.
<ddfreyne> Hmm, I'd like to split that out actually
<ddfreyne> What about data sources?
<ddfreyne> OK, removing the data sources is actually goign to be a hard problem, because a lot of tests in core depend on the filesystem data source (generate a site, add data, compile, check result)
<bobthecow> i'd leave one data source in core
<bobthecow> i don't think core has to be completely gutted.
<bobthecow> alternatively, you could write a "mem" data source for testing.
<ddfreyne> bobthecow: Yeah. I'd actually keep erb in core then, too...
<bobthecow> remove a filesystem dependency totally :)
<ddfreyne> (a lot of tests in core also use erb)
<ddfreyne> bobthecow: I don't really need one. It's quite easy to stub a data source
<ddfreyne> bobthecow: I'm pretty happy with what I have now. You OK with the gist?
<ddfreyne> bobthecow: What about not using sub-categories such as "filters" and "helpers" in names? e.g. nanoc-blogging instead of nanoc-helpers-blogging
<bobthecow> would make it easier for things that are cross-category
<bobthecow> and the possibility of namespace or mental collisions is fairly small.
<bobthecow> plus, things like nanoc-sass might include sass helpers?
<ddfreyne> Yeah, agreed
<bobthecow> the only one i don't know about is nanoc-helpers-text
<bobthecow> nanoc-text is a bit odd.
<ddfreyne> bobthecow: nanoc-text-helper? nanoc-blogging-helper?
<ddfreyne> Putting the -filter and -helper at the back makes more sense
<ddfreyne> (for everything)
<bobthecow> it does seem like most of 'em don't need that at all though.
<bobthecow> nanoc-coffeescript says to me "this is what i need to use coffeescript with nanoc"
<bobthecow> which would be a filter.
<bobthecow> nanoc-blogging says "this is how you blog with nanoc" which would be helpers, maybe data sources or something else?
<bobthecow> honestly, the only one i don't get immediately is 'nanoc-text' ... and that helper could just be dropped :P
<ddfreyne> Yeah, text is... sucky
<ddfreyne> And it has TODOs and FIXMEs etc :D
<ddfreyne> strip_html... seriously :(
<ddfreyne> bobthecow: I'll let this rest for a bit and get back to it later
LBo has joined #nanoc
louquillio has joined #nanoc
terinjokes has joined #nanoc
<terinjokes> i have an issue deploying my site: "RuntimeError: Could not read layouts/default.haml because the file is not valid US-ASCII."
<terinjokes> this is true, it's utf-8, but I have "-# coding: utf-8" at the top of the file
<ddfreyne> terinjokes: the coding/encoding thing only applies to .rb files. Check out http://nanoc.ws/docs/troubleshooting/#characters-don-t-show-up-right-in-the-output
<terinjokes> ddfreyne: i cant even output
<terinjokes> i get a runtime error and nanoc sinks
<terinjokes> ah
<terinjokes> "nanoc defaults to the current environment encoding" << buildbox has this set to US_ASCII
<ddfreyne> terinjokes: Add encoding: utf-8 to your config (see bottom of that page)
<terinjokes> ddfreyne: yep, done and built on the buildbox correctly
<bobthecow> ddfreyne: nanoc-fog-deployer vs nanoc-deployers-fog?
<bobthecow> i'd lean toward the former.
<terinjokes> was wondering why it worked locally, but not on the buildbox
<bobthecow> ddfreyne: mebbe we should catch encoding errors and give a message with a link to that troubleshooting page?
<ddfreyne> bobthecow: Yeah, the former is much nicer.
<ddfreyne> terinjokes: The good news is that nanoc 4.0 will always default to UTF-8 and not care about the environment :D
<terinjokes> yippy
<ddfreyne> bobthecow: Catching encoding errors is a good idea
<terinjokes> i'm just a bit surprised this site I pulled from backups still works
<ddfreyne> bobthecow: I just realised there is no Trello board for nanoc 3.x. Let's fix that! https://trello.com/b/pSVvuUfR/nanoc-3-x
<ddfreyne> terinjokes: Backwards compatibility rocks!
<ddfreyne> bobthecow: Have you looked at https://github.com/nanoc/nanoc/issues/325?
<ddfreyne> I remember saying you did
<bobthecow> i didn't try it, i just run into that error periodically while guarding.
<bobthecow> and thought that looked like a reasonable solution.
<terinjokes> ddfreyne: this old site was deployed to a dokku instance using https://github.com/terinjokes/heroku-buildpack-nanoc (bobthecow, sent you a pull request)
<bobthecow> merged.
<ddfreyne> bobthecow: Stuff that could be extracted from nanoc and into plugins would be the output diff generator
<ddfreyne> It's currently part of CLI (ew)
<ddfreyne> bobthecow: Could use your feedback on my proposed subdirectory structure: https://gist.github.com/ddfreyne/6206130
<bobthecow> needs a `lib/nanoc-asciidoc.rb`, too, right?
<bobthecow> so that bundler can auto-require?
<ddfreyne> Ah yeah, true
<ddfreyne> Do you agree with having lib/nanoc-asciidoc instead of lib/nanoc/filters/asciidoc? The latter is much more cumbersome, and makes it depend on the directory structure used by nanoc
<bobthecow> i can see that...
<bobthecow> that said, guard doesn't do that.
<bobthecow> and they're the best example i can think of for a wildly extended base gem.
<ddfreyne> True... are there advantages of doing it the guard way?
<bobthecow> require 'nanoc/filters/asciidoc'
<bobthecow> instead of
<bobthecow> require 'nanoc-asciidoc/filters/asciidoc'
<ddfreyne> require 'nanoc-asciidoc' ?
<ddfreyne> There's no reason why you would require only that specific filter, I imagine
<bobthecow> activerecord plugins tend to do that as well.
<bobthecow> trying to figure out what other projects have lots of plugins.
<bobthecow> those are really the only two i came up with.
<ddfreyne> Yeah
<bobthecow> sprockets
<ddfreyne> Ok, so it seems that most projects actually do it that way
<bobthecow> they all tend to have the 'lib/foo-bar.rb` then put their code in 'lib/foo/...'
<ddfreyne> bobthecow: It does seem to me that nanoc-sass should go in lib/nanoc/sass then, not lib/nanoc/filters/sass + lib/nanoc/helpers/sass (assuming there would be sass helpers)
<ddfreyne> That means it does not depend on the nanoc directory structure, which is good
<bobthecow> well, it's not really depending on it anyway.
<bobthecow> just mirroring it.
<bobthecow> because if nanoc changed, it'd still work.
<bobthecow> but yeah,
<ddfreyne> Yeah, so let's do it this way
<bobthecow> lib/rack/sass/... wouldn't be so bad.
<bobthecow> for simple ones, it could be 'lib/rack/sass.rb' :)
<bobthecow> that's rack-ssl
<ddfreyne> Yep
<ddfreyne> I like having a separate version.rb in any case
<ddfreyne> So I'd definitely add that
<ddfreyne> There needs to be a root file (e.g. lib/rack/ssl.rb) but anything else is optional. Agreed?
<bobthecow> lib/nanoc/sass/version.rb
<bobthecow> lib/nanoc-sass.rb
<bobthecow> lib/nanoc/sass.rb
<bobthecow> no, the root file is lib/gemname.rb
<bobthecow> lib/nanoc-sass.rb
<bobthecow> (notice how rack-ssl has one of those too)
<bobthecow> that's the one that's auto-required by bundler.
<bobthecow> and it can set up whatever else it wants.
<bobthecow> oh, rack ssl doesn't have one.
<ddfreyne> Ahhh
<bobthecow> most of the rack ones do.
<bobthecow> and they look like that.
<bobthecow> but that's so you don't have to do `gem 'nanoc-sass', require: 'nanoc/sass'` in your gemfile
<ddfreyne> Yeah, that sucks
<ddfreyne> bobthecow: I still don't get why there would be an advantage to doing lib/nanoc/blah instead of lib/nanoc-blah though
<bobthecow> because that's how everyone else does it :)
<bobthecow> i think the mentality is "this gem is providing extra functionality for that other gem, let's namespace it there"
<ddfreyne> bobthecow: Why have lib/nanoc/sass.rb though?
<ddfreyne> It's not the root one (that would be lib/nanoc-sass.rb)
<bobthecow> right, but the root one requires that one.
<ddfreyne> I'd rather have lib/nanoc/sass/filter.rb
<bobthecow> whatever.
<bobthecow> it might actually make sense to keep 'em namespaced.
<bobthecow> lib/nanoc/filters/sass.rb
<bobthecow> so nanoc-sass requires 'nanoc/filters/sass'
<bobthecow> thinking about mapping modules to filenames.
<bobthecow> class Nanoc::Filters::Sass
<ddfreyne> That goes against the practices of the other extension gems, though
<bobthecow> lib/nanoc-sass.rb
<bobthecow> lib/nanoc/filters/sass.rb
<bobthecow> lib/nanoc/filters/sass/version.rb
<bobthecow> lib/nanoc/filters/scss.rb
<ddfreyne> Nah, I don't like that approach
<bobthecow> the difference is, you extend rack in one way.
<bobthecow> you extend guard in one way.
<bobthecow> you extend activerecord in (approximately) one way.
<bobthecow> you extend nanoc in four ways.
<ddfreyne> bobthecow: filters, helpers, ... being the four ways?
<bobthecow> deployers, data sources.
<bobthecow> yep.
<ddfreyne> bobthecow: If nanoc is entirely split up, though, there won't be a Nanoc::Filters anymore, no Nanoc::Helpers etc
<bobthecow> right, but think about it mashed back together again.
<bobthecow> because that's what the virtual "directory" assembled by bundler looks like.
<bobthecow> it's not a *bad* thing to put things in lib/nanoc/sass/ in the main project.
<bobthecow> that's definitely a valid way to organize things.
<bobthecow> but is that what you want?
<bobthecow> (just devil's advocating here, i think either way works)
<ddfreyne> bobthecow: Yeah, I see your point
<bobthecow> that said, look at your main project directory.
<ddfreyne> bobthecow: Few people care about the stuff in Bundler though
<bobthecow> most of that will be moved into sub-gems or flattened, right?
<ddfreyne> bobthecow: nanoc-core will be in lib/nanoc/core. Right?
<bobthecow> or lib/nanoc/
<bobthecow> the main project can cheat :)
<bobthecow> since you'll want, for example, Nanoc::Item
<bobthecow> that should be lib/nanoc/item.rb
<ddfreyne> Ahh, true
<bobthecow> but the rest of it.
<ddfreyne> Although... it does not need to be in there
<bobthecow> filters is gone
<bobthecow> helpers is gone
<bobthecow> base is flattened into nanoc-ore
<bobthecow> *core
<bobthecow> because that's what core is.
<bobthecow> cli is gone
<bobthecow> data_sources only has one thing in it now, so it might as well be gone.
<ddfreyne> bobthecow: I rearranged base/ actually, so it contains directories for entities/ for example (entities being item, site, etc)
<bobthecow> so all that's left is extras
<ddfreyne> bobthecow: interactors/ for things that perform tasks (SiteLoader, Compiler)
<bobthecow> so that moves up a level.
<ddfreyne> bobthecow: and stores/ which contain data
<ddfreyne> bobthecow: so it's still lib/nanoc/entities and there are no loose files in lib/nanoc/ anymore (except lib/nanoc/entities.rb perhaps, to ease loading)
<bobthecow> version is still loose.
<ddfreyne> But if I'm not matching the directory structure to the class/module naming anymore (there is no Nanoc::Entitities::Item), I might use lib/nanoc/core too, allowing other people to use lib/nanoc/WHATEVER and not worry about overwriting anything by accident
<ddfreyne> bobthecow: yeah, version.rb is in there obviously
<bobthecow> yeah, that makes sense too.
<bobthecow> your nanoc/base subdirectories are inconsitently pluralized.
<bobthecow> :)
<bobthecow> so would the class provided by nanoc-sass still be Nanoc::Filters::Sass?
<bobthecow> or could it be Nanoc::Sass << Nanoc::Filter
<bobthecow> ?
<ddfreyne> bobthecow: Nanoc::Sass::Filter I think
<ddfreyne> bobthecow: because it'd be in lib/nanoc/sass/filter.rb
<bobthecow> but does it have to be?
<ddfreyne> bobthecow: and because there could also be a Sass helper
<bobthecow> take joe's super simple filter.
<bobthecow> one class.
<ddfreyne> bobthecow: No, could also be Nanoc::Sass I guess
<bobthecow> so it doesn't depend on being a constant in Nanoc::Filters?
<ddfreyne> bobthecow: No, otherwise nanoc-core needs to define Nanoc::Filters
<bobthecow> ahh. Nanoc::PluginRegistry
<ddfreyne> bobthecow: One thing that still needs to be figured out is how to load/require plugins. What if you do filter :sass? Where is it going to find the filter?
<bobthecow> make things that extend Nanoc::Filter register themselves.
<ddfreyne> Explicit requires could work but are inconvenient. Trying to guess the plugin name?
<bobthecow> the requires are handled by bundler, remember?
<ddfreyne> bobthecow: Sure, but the code isn't loaded because it is not required yet
<bobthecow> that's why lib/nanoc-sass.rb is a thing
<ddfreyne> bobthecow: does Bundler require *everything*?
<ddfreyne> Or does it just do that on demand?
<bobthecow> depends whether you do Bundler.setup() or Bundler.require() iirc.
<bobthecow> that's how you're supposed to do it.
<bobthecow> that's how rails does it.
<bobthecow> you can force it not to for a given gem
<bobthecow> gem "foo", require: false
<ddfreyne> Ahh, good
<bobthecow> Bundler.require(*Rails.groups(assets: %w(development test)))
<bobthecow> so the idea is, you put things that aren't *required* into a group.
<bobthecow> Bundler.require(:default, Rails.env)
<bobthecow> something like that.
<ddfreyne> Does nanoc need to care about groups?
<bobthecow> prolly not.
<bobthecow> mebbe test for bigger projects.
<bobthecow> if a project has tests.
<ddfreyne> People who want groups for their nanoc sites can require it themselves, I guess
<bobthecow> that way it wouldn't require extra stuff.
<bobthecow> right, that's just for users.
<ddfreyne> require the groups, I mean.
<bobthecow> so once we move to nanoc.rb in the project root...
<ddfreyne> Is :default a magic group?
<bobthecow> yeah
<bobthecow> why not make the first line of nanoc.rb:
<bobthecow> Bundler.require(:default) if defined?(Bundler)
<bobthecow> make it explicit, then people can override it if they don't want everything auto-required.
<bobthecow> or if they want to change groups, or whatever.
<ddfreyne> Yeah, I was thinking the same
<ddfreyne> bobthecow: Hmm. Should nanoc-core have lib/nanoc/version.rb? That is getting a bit icky...
<bobthecow> so the responsibility of the user is either to use a Gemfile properly, or to `require 'nanoc-sass'` at the top of their rules file.
<bobthecow> it can be in nanoc/core/version.rb
<bobthecow> wouldn't hurt.
<bobthecow> s/rules file/config file/
<ddfreyne> The config file is YAML though so it will have to be in the Rules file :)
<bobthecow> i thought we were moving to .rb config file?
<ddfreyne> Ah right
<ddfreyne> I'm thinking the Old Way still
<ddfreyne> ;)
<ddfreyne> It's mentioned in the Trello card
<bobthecow> yep.
<bobthecow> i went to make a nanoc sample site so i could play with config / require / bundler type stuff, and found that same thing in my tmp project directory :P
<bobthecow> so yeah, that's the exact same file.
<ddfreyne> One thing still bugs me. nanoc-cli should require nanoc-core, and not nanoc, right?
<bobthecow> correct.
<ddfreyne> nanoc-core defines Nanoc, Nanoc::VERSION, etc.
<bobthecow> yeah.
<ddfreyne> Possibly has lib/nanoc/version.rb instead of lib/nanoc/core/version.rb?
<bobthecow> lib/nanoc/core/version.rb isn't a bad thing.
<bobthecow> for the same reason moving the rest of core into there isn't a bad thing.
<bobthecow> but it also has `lib/nanoc-core.rb`
<bobthecow> which requires whatever core requires.
<ddfreyne> With the 'nanoc' gem having a lib/nanoc/version.rb that is basically the same as lib/nanoc/core/version.rb?
<ddfreyne> (or rather, the former requires the latter?)
<ddfreyne> This would be just for convenience, btw
<bobthecow> or maybe the nanoc gem doesn't have a version at all.
<bobthecow> because it's a meta-package comprised of core, cli, etc.
<bobthecow> so if you ask "what version of nanoc are you running" you're talking about nanoc/core/version.rb
<ddfreyne> bobthecow: gem update nanoc <- nothing to update?!
<ddfreyne> bobthecow: I think nanoc, nanoc-core and nanoc-cli should all have a version number, and all the same
<bobthecow> right, but they all grab 'em out of nanoc-core
<ddfreyne> Yes
<bobthecow> and nanoc gem has a hard dependency on the exact same version number of nanoc-core and nanoc-cli
<bobthecow> nanoc v1.2.3 depends on nanoc-core v1.2.3, nanoc-cli v1.2.3
<ddfreyne> Yeah
<ddfreyne> Rails-style, because these three things are pretty tightly coupled
<bobthecow> right.
<ddfreyne> Is there a lib/nanoc-cli/version.rb? I guess people could expect Nanoc::CLI::VERSION to exist
<bobthecow> it would mean you'd have to publish them in the right order :)
<bobthecow> it doesn't now.
<ddfreyne> Yeah, deployment isn't going to be as easy as it is now
<bobthecow> i think you get to make up rules.
<ddfreyne> It doesn't know, but that is because there is no nanoc-cli gem
<bobthecow> i'd say either it proxies, or it doesn't have one.
<bobthecow> my vote is for doens't have one.
<ddfreyne> For consistency, I think it should proxy
<bobthecow> since nanoc-cli has a hard dependency on an exact version of nanoc-core, anyone using nanoc-cli and expecting a version will already have a Nanoc::VERSION
<bobthecow> which is what they have now.
<ddfreyne> (For consistency, there should also be a Nanoc::Core::VERSION but that is icky)
<ddfreyne> Yeah, alright
<bobthecow> no, because there's no Nanoc::Core, remember?
<ddfreyne> Indeed
<ddfreyne> bobthecow: OK with the Versioning section of https://gist.github.com/ddfreyne/6206130 ?
<bobthecow> with semver, deployment doesn't have to get much harder.
<bobthecow> make a bash script to push nanoc-cli then nanoc-core then nanoc.
<ddfreyne> publish nanoc-core, nanoc-cli, nanoc
<bobthecow> right.
<ddfreyne> Core first
<bobthecow> but the rest of the gems don't complicate things at all.
<ddfreyne> And yes, I was definitely planning on automating that :)
<bobthecow> they're all managed independently.
<ddfreyne> true
<bobthecow> and make nanoc gem depend on twiddle-wakkas of the gems it uses (other than core and cli, of course)
<ddfreyne> +1 for the term twiddle-wakka :D
<ddfreyne> Alright, cool... anything else that needs to be done?
<ddfreyne> Or discussed before I can start ripping this project apart? Haha
<bobthecow> deployers/checks still have the `nanoc-deployers-*` names
<ddfreyne> nanoc-rsync-deployer and nanoc-html-check are OK, right?
<bobthecow> yep.
<bobthecow> or nanoc-rsync_deployer
<bobthecow> that's probably more technically correct.
<bobthecow> but that always rubs me wrong :)
<ddfreyne> Agreed... let's not mix - and _
<ddfreyne> external_links should then become external-links too
<bobthecow> then it'd have to stay nanoc-deployer(s)-rsync
<ddfreyne> nanoc-external-links-check
<bobthecow> the problem is, that's not the Gem way.
<ddfreyne> That is true...
<ddfreyne> OK, let's use nanoc-foo_bar_baz style in this case. Icky, I prefer it over nanoc-deployers-rsync
<bobthecow> gemname.split('-').reverse.join(' is an extension of ')
<ddfreyne> Yeah
<ddfreyne> Updated the gist
<ddfreyne> There's already nanoc-colorize_syntax, nanoc-relativize_paths etc anyway
<ddfreyne> (Somewhat OT: nanoc-html_escape should be called nanoc-html_escaping instead)
<bobthecow> might as well move it while you've got the chance.
<bobthecow> should keep a (temporary?) file in the repo with a list of things that have moved.
<bobthecow> to make it easier to say "upgrade your site by changing references from HtmlEscape to HtmlEscaping"
<ddfreyne> link_to -> linking
<ddfreyne> Yeah
<ddfreyne> bobthecow: https://github.com/nanoc/nanoc/wiki/4.0-Development has a list of user-visible changes
<ddfreyne> It is incomplete already though :)
<bobthecow> honestly, i'd keep in in the repo.
<bobthecow> makes it easier to keep in sync.
<bobthecow> just a bulleted list of "this -> that"
<ddfreyne> !urban breadcrumbing
<number-six> The act of sending out flirtatious, but non-committal text messages (ie "breadcrumbs") to one or more members of the opposite sex in order to lure a sexual partner without expending much effort.
<ddfreyne> TIL
<bobthecow> huh.
<ddfreyne> Not sure what to do with the breadcrumbs helper name :D
<bobthecow> site_mapping
<ddfreyne> sitemap_generation
<ddfreyne> generating,r ather
<ddfreyne> Maybe the -ing suffix is a bit odd
<bobthecow> breadcrumb_generating
<ddfreyne> I have the feeling it makes sense, though
<bobthecow> Nanoc::Capture is kinda weird.
<ddfreyne> -ing or -ion would both work
<bobthecow> Nanoc::Linking ... Nanoc::Escaping ... Nanoc::Filtering
<bobthecow> yeah, those all work.
<bobthecow> Nanoc::SitemapGeneration
<bobthecow> Nanoc::BreadcrumbGeneration
<ddfreyne> Nanoc::Texting :D
<ddfreyne> Nah, we agreed to get rid of that one
<bobthecow> :)
<bobthecow> I feel like Nanoc::Escaping would be better than html escaping
<bobthecow> because then you could add js escaping too.
<bobthecow> right now i use .inspect on strings to get 'em into js variables, but that's a bit ugly :P
<ddfreyne> bobthecow: I agree
<terinjokes> bobthecow: is there a reason for the buildpack to be using apache over nginx? and what's the PHP support for?
<ddfreyne> test
<bobthecow> terinjokes: apache over nginx because of php.
<ddfreyne> bobthecow: PHP?!
<terinjokes> why does there need to be PHP support?
<bobthecow> terinjokes: php because that's a common thing for people to magic just a little bit of their nanoc sites with.
<bobthecow> contact forms and stuff.
<bobthecow> redirects.
<bobthecow> whatever.
<ddfreyne> can somebody highlight my nick here? Testing out an improved irssi theme (about time)
<terinjokes> ddfreyne:
<ddfreyne> (Something I wrote a long time ago)
<bobthecow> terinjokes: that said, i've meant to rewrite that buildpack for ages.
<bobthecow> so if you've got a minute :)
<terinjokes> bobthecow: i see, i'll probably fork more then
<bobthecow> no!
<terinjokes> ?
<bobthecow> let's talk about what i plan to do with it.
<bobthecow> then you can help build that :P
<terinjokes> bobthecow: yes, i wrote that before i saw your reply
<bobthecow> so heroku buildpacks tend to be monolithic and not super flexible.
<terinjokes> yes, happy to talk about a rewrite
<bobthecow> that's what the initial nanoc buildpack was.
<bobthecow> *but* they don't have to be.
<bobthecow> so i started a rewrite to make a composable nanoc buildpack.
<terinjokes> i've seen some that use the ENV to determine what to build in
<bobthecow> essentially, a minimal ruby buildpack that knows how to install and compile a nanoc site, then uses rack-static to serve it.
<bobthecow> then you'd use the multi buildpack to define other ones to layer on top.
<bobthecow> so in your case, it'd prolly be nginx + nanoc buildpacks.
<bobthecow> nanoc to compile, nginx to run the actual binary.
<bobthecow> in my case, it'd be nginx + php + nanoc
<bobthecow> because i have those php files for contact forms and stuff.
<terinjokes> yea, that works
<terinjokes> i've got to run to catch the train, but I can pop on later to discuss farther
<bobthecow> that's the start of it.
<terinjokes> great, awesome!
<bobthecow> that is the ruby buildpack, but gutted so it doesn't do all the crap the ruby buildpack does.
<bobthecow> and it adds support for defining rake tasks for pre- and post- compile things, and stuff like that.
<bobthecow> it's pretty rough still, but that's where i was headed.
<bobthecow> actually, looking at it now, it doesn't look as rough as i thought it was.
<bobthecow> it might actually be usable.
<bobthecow> check the readme when you get a minute.
<bobthecow> it doesn't talk about using this to build a composable stack of stuff, but it covers using the buildpack by itself.
<ddfreyne> I'd love to see SoundCloud's Heroku clone being open-sourced. It's pretty awesome
<ddfreyne> I'm pretty happy at SoundCloud. A great change :D
louquillio has quit [Remote host closed the connection]
louquillio has joined #nanoc
* ddfreyne is off to sleep. gnight!
<bobthecow> 'night
cDlm has joined #nanoc
<terinjokes> bobthecow: awesome