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
Rym has joined #nanoc
<bobthecow> ddfreyne: should nanoc-site be renamed to nanoc.ws?
pavelkunc has quit [Quit: Leaving.]
Rym has quit [Ping timeout: 240 seconds]
Rym has joined #nanoc
Rym has quit [Quit: Rym]
louquillio has joined #nanoc
skroon has joined #nanoc
skroon has quit [Ping timeout: 245 seconds]
skroon has joined #nanoc
skroon_ has joined #nanoc
skroon has quit [Ping timeout: 245 seconds]
<ddfreyne> bobthecow: I'd be in favour of that, yes
dbast has quit [Quit: '']
dbast has joined #nanoc
yogsototh has joined #nanoc
skroon_ has quit [Ping timeout: 240 seconds]
pavelkunc has joined #nanoc
cDlm has quit [Ping timeout: 276 seconds]
cDlm has joined #nanoc
skroon has joined #nanoc
yogsototh1 has joined #nanoc
yogsototh has quit [Ping timeout: 246 seconds]
yogsototh1 has quit [Ping timeout: 264 seconds]
skroon has quit [Ping timeout: 264 seconds]
yogsototh has joined #nanoc
skroon has joined #nanoc
jugglinmike has joined #nanoc
skroon_ has joined #nanoc
skroon has quit [Ping timeout: 268 seconds]
<guardian> I don't know how I feel about the many nanoc-* repositories
<guardian> are there going to be submodules of nanoc repository?
<ddfreyne> guardian: No
<ddfreyne> There will be dependencies, though (gemspec dependencies)
skroon_ has quit [Ping timeout: 268 seconds]
skroon has joined #nanoc
<guardian> what does this solve in practice?
<ddfreyne> guardian: nanoc tests fail almost always, because there are 20 dependencies and some of them have native extensions with other dependencies etc
<ddfreyne> It also makes it easier to pass on maintainership if necessary
skroon has quit [Ping timeout: 240 seconds]
skroon has joined #nanoc
skroon has quit [Read error: Operation timed out]
<musicmatze> hi there, whats going on?
skroon has joined #nanoc
skroon_ has joined #nanoc
skroon has quit [Ping timeout: 240 seconds]
skroon has joined #nanoc
skroon_ has quit [Ping timeout: 245 seconds]
yogsototh1 has joined #nanoc
<ddfreyne> heya musicmatze
<ddfreyne> guardian: In addition, it will allow the tests to run much faster
<ddfreyne> and encourage decoupling
yogsototh has quit [Ping timeout: 246 seconds]
<smkelly> So in bootstrap 3, you got these fonts/ files. There are 4 files, all with the same file name but different extension. How do I properly handle that in nanoc?
yogsototh1 has quit [Remote host closed the connection]
<guardian> static data source
pavelkunc has quit [Ping timeout: 245 seconds]
<ddfreyne> smkelly:
<ddfreyne> You upgrade to nanoc 4.0.0a1 :P
<ddfreyne> Or:
<ddfreyne> The latter is recommended. The former not so much (yet) :)
<ddfreyne> musicmatze: Link me again to that github issue... I lost the link
<ddfreyne> (the cri one)
pavelkunc has joined #nanoc
<smkelly> mmmm, nanoc 4. now I must investigate this
cDlm has quit [Ping timeout: 264 seconds]
<smkelly> I had no idea there was a static data source. that is all kinds of helpful
<smkelly> ok got it working, thanks!
<musicmatze> ddfreyne: What issue do you mean?
cDlm has joined #nanoc
hod_ has joined #nanoc
<hod_> hi
<hod_> I'm looking for a static blog generator and i started to compare some features. Actually I'm looking for something to write my papers only in LaTeX and I did not notice something about that on nanoc website. Is that possible to use LaTeX with nanoc ?
pavelkunc has quit [Quit: Leaving.]
pavelkunc has joined #nanoc
<cDlm> hod_: sure
<cDlm> hod_: nanoc can run arbitrary commands, so you could call hevea or other to generate pages from LaTeX
guardian has quit [Ping timeout: 264 seconds]
<hod_> Ok. Thank your for you answer. I do not know Hevea. Is that 'better' than pandoc ?
<hod_> I mean in the ouput
<cDlm> no clue
<hod_> So I will try both.
<cDlm> there is a tex2html as well
<hod_> Yeah, but i'm not convinced by the output
<cDlm> it really depends how complex your TeX code is
<hod_> Or maybe it's a bit tricky to obtain what I want
guardian has joined #nanoc
<hod_> well strange I never heard about Hevea since it is developped by a team in the same research center than I am... ><
<cDlm> lol
<cDlm> french advertisement at work
<hod_> x)
pepijndevos has quit [Ping timeout: 240 seconds]
pepijndevos has joined #nanoc
pepijndevos has quit [Ping timeout: 240 seconds]
pepijndevos has joined #nanoc
alerante has joined #nanoc
Rym has joined #nanoc
Rym has quit [Ping timeout: 245 seconds]
<ddfreyne> musicmatze: The one with cri
<ddfreyne> musicmatze: Oh nm, that is not you
<ddfreyne> doh
pavelkunc has quit [Quit: Leaving.]
pavelkunc has joined #nanoc
<bobthecow> guardian: splitting filters into their own repos and gems means that their releases are decoupled.
<bobthecow> so when someone has a quick fix for the HAML filter, it doesn't have to wait for a full nanoc release.
<bobthecow> likewise, filters like HAML can make backwards incompatible changes if they want/need, while nanoc core can't.
<ddfreyne> ^- that
hod_ has quit [Ping timeout: 250 seconds]
<guardian> ok
<gkarekinian> It also makes doing SemVer a bit easier now that I think about it
<ddfreyne> gkarekinian: Hm, not sure. I think it becomes more complicated, in some ways
<ddfreyne> gkarekinian: On the other hand, I did some ugly hacks with different versions in filters
<gkarekinian> I was also thinking the same thing, versioning is hard
<ddfreyne> Versioning is hard
<ddfreyne> Let's go shopping!! !!
<ddfreyne> Luckily, this is a very old commit :)
<ddfreyne> That supports two versions of RDoc right there...
skroon has quit [Ping timeout: 268 seconds]
skroon has joined #nanoc
<gkarekinian> It's like supporting the regular universe, and bizarro universe at the same
<gkarekinian> In that case you can probably use some emoji as the patch version
<bobthecow> gkarekinian ddfreyne: actually, decoupled makes semver really easy.
<bobthecow> because each filter and data source and everything can depend on whatever it needs to depend on, and bundler will handle finding the latest version for you.
<bobthecow> and the API for the filters themselves won't change, so nanoc core won't have to bump major versions to depend on new versions of filter dependencies.
<ddfreyne> There is no coupling between versionf of the main projects (nanoc, nanoc-cli, nanoc-core) and the subprojects but I think that is fine
<bobthecow> agreed.
<ddfreyne> bobthecow: should the versios of nanoc, nanoc-cli, nanoc-powerpack and nanoc-core be linked?
<bobthecow> yes.
<bobthecow> nanoc, nanoc-cli and nanoc-core should be version bumped in lockstep.
<bobthecow> the same way rails and activerecord are.
<bobthecow> nanoc powerpack, too, now that i think about it.
<ddfreyne> Yeah, makes sense
skroon has quit [Ping timeout: 260 seconds]
<ddfreyne> bobthecow: What about nanoc-web if that ever appears?
<bobthecow> but since none of them depend on explicit versions of filters and such, those can be released and updated independently.
<bobthecow> i feel like nanoc-web *could* be released on its own schedule.
<bobthecow> a la resque-web
<ddfreyne> What makes it different from nanoc-cli though?
skroon has joined #nanoc
<bobthecow> nanoc-cli is the canonical interface.
<ddfreyne> nanoc-cli is not bound to change very often either, I think
<bobthecow> but it's going to get its version from nanoc.
<bobthecow> Nanoc::VERSION
<ddfreyne> bobthecow: So there could be a nanoc-cli 4.0.0 followed by a nanoc-cli 4.0.6? Nothing in between
<ddfreyne> ?
<bobthecow> because when you run `nanoc --version` or `nanoc version` or whatever, you don't care about what version the bin wrapper is, you care about what version of nanoc you're talking about.
<bobthecow> no, it should be released at the same time as nanoc-core, every time.
<bobthecow> even if it doesn't do anything.
<bobthecow> just depends on the next higher version of nanoc-core.
<ddfreyne> Yeah, makes sense
<bobthecow> so any release to nanoc, nanoc-core or nanoc-cli would bump the version and dependency of each of those.
<bobthecow> make 'em == dependencies.
<bobthecow> not ~> or whatever.
<ddfreyne> Yep
<bobthecow> i could see keeping nanoc-web in lockstep the same way.
<bobthecow> for the same "what version of nanoc is this?" reason.
<bobthecow> i mean, it's just a matter of writing a shell script to bump versions and batch releases, what's one more (theoretical) gem release to add to the mix?
<bobthecow> but i don't feel as strongly about nanoc-web as i do about nanoc-cli.
<ddfreyne> nanoc-web is a bit more theoretical anyway :(
<bobthecow> :)
<bobthecow> added bonus of the gem segregation: we can "bless" third-party filters and move 'em into the nanoc org on github, but keep the original author as maintainer.
<ddfreyne> Yes, indeed
<ddfreyne> the nanoc+fog integration was nice, but it shouldn't really have been part of nanoc
<ddfreyne> (nanoc-deploy gem actually is owned by the original author, so I'd like to get back in touch with him and take that over)
<ddfreyne> Alright, I'm off to sleep
<ddfreyne> gnight!
<bobthecow> ddfreyne: https://github.com/ttscoff/jtag
<bobthecow> would be awesome to see a `nanoc-frontmatter` gem that adds a command just like that :)
<bobthecow> mebbe i'll implement it if i ever have an hour or two of free time.
<bobthecow> i mean, not just tags, but everything.
<bobthecow> hmm. actually, it looks like it's not editing the content files.
<bobthecow> that's what i was thinking.
<bobthecow> a command to manage yaml frontmatter across your whole site.
<bobthecow> autogenerate tags, etc.
nakp has joined #nanoc
nakp has left #nanoc ["Saliendo"]
jugglinmike has quit [Quit: Leaving.]
pavelkunc has quit [Quit: Leaving.]
pavelkunc has joined #nanoc
pavelkunc has quit [Client Quit]