<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>
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.
<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>
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...]
<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.
<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>
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?
<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>
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>
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?
<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