ddfreyne changed the topic of #nanoc to: 3.6.7 (dec 9th) | 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
sahinmehmet has joined #nanoc
sahinmehmet has quit [Remote host closed the connection]
guardian has quit [Ping timeout: 240 seconds]
TobiasFar_ has quit [Ping timeout: 240 seconds]
TobiasFar has joined #nanoc
antognolli has quit [Ping timeout: 265 seconds]
dkm has quit [Ping timeout: 265 seconds]
antognolli has joined #nanoc
antognolli has quit [*.net *.split]
louquillio has quit [*.net *.split]
forcev has quit [*.net *.split]
jaspervdj has quit [Ping timeout: 244 seconds]
jugglinmike has quit [Quit: Leaving.]
tlevine has quit [*.net *.split]
Jutah has quit [*.net *.split]
number-six has quit [*.net *.split]
tlevine has joined #nanoc
guardian has joined #nanoc
antognolli has joined #nanoc
forcev has joined #nanoc
jaspervdj has joined #nanoc
dkm has joined #nanoc
Jutah has joined #nanoc
louquillio has joined #nanoc
number-six has joined #nanoc
number-six has quit [Excess Flood]
number-six has joined #nanoc
alerante has joined #nanoc
alerante has quit [Ping timeout: 265 seconds]
guardian has quit [Quit: Coyote finally caught me]
guardian has joined #nanoc
dbast has left #nanoc ["Palaver http://palaverapp.com/"]
relix has joined #nanoc
alerante has joined #nanoc
alerante has quit [Changing host]
alerante has joined #nanoc
alerante has quit [Ping timeout: 240 seconds]
relix has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
alerante has joined #nanoc
alerante has quit [Ping timeout: 252 seconds]
relix has joined #nanoc
alerante has joined #nanoc
jugglinmike has joined #nanoc
strictor has joined #nanoc
VitamineD has joined #nanoc
strictor has quit [Ping timeout: 244 seconds]
alerante has quit [Remote host closed the connection]
alerante has joined #nanoc
alerante has quit [Ping timeout: 240 seconds]
VitamineD has quit [Quit: Leaving.]
VitamineD has joined #nanoc
relix has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
VitamineD has quit [Quit: Leaving.]
VitamineD has joined #nanoc
alerante has joined #nanoc
alerante has quit [Ping timeout: 240 seconds]
<ddfreyne> Hm.
<bobthecow> ddfreyne: i don't get why distro packaging even matters.
<ddfreyne> bobthecow: Getting a package into the distro repository takes a long time
<ddfreyne> bobthecow: As in, many months
<bobthecow> right. so why put it in there at all?
bobthecow has left #nanoc ["Linkinus - http://linkinus.com"]
bobthecow has joined #nanoc
<ddfreyne> bobthecow: Put it in the distro's repo you mean?
<bobthecow> what's wrong with `gem install nanoc`?
<bobthecow> yeah.
<bobthecow> i get it if it's something complicated that compiles and depends on all sorts of libraries and stuff.
<bobthecow> but this is pure ruby.
<bobthecow> why put it in distros at all?
<ddfreyne> bobthecow: people want to be able to do apt-get install nanoc, or pacman -S nanoc, or yum install nanoc
<bobthecow> but why.
<bobthecow> that just means there'll be an always out of date version of nanoc that you installed a dumb way.
<ddfreyne> And I understand having only one repository with software. Why should people have to use two different tools to install a software package? (i.e. apt-get install ruby and gem install nanoc, instead of just apt-get install nanoc)
<VitamineD> apt should rely on gem for ruby software
<VitamineD> I think brew does that
<bobthecow> i feel like homebrew makes the right call
<ddfreyne> bobthecow: I get what you're saying
<ddfreyne> Oh?
<bobthecow> it doesn't include anything that is in pip or gems or npm.
<bobthecow> there's a package manager for all of those. it works perfectly well. use it.
<ddfreyne> It's a bit of a heated issue that I'd like to avoid
<bobthecow> in fact, it's specifically against the rules of homebrew to add packages that are managed elsewhere.
<bobthecow> do it right, even if it inconveniences package maintainers.
<bobthecow> we shouldn't compromise the experience of people using bundler (like they should) because someone else thinks it'd be awesome to install all their gems using a tool made for compiling c libraries.
<bobthecow> otherwise we're just feeding the dependency hell.
<bobthecow> ddfreyne: should i be able to do `npm install nanoc` too? How 'bout `bower install nanoc`?
alerante has joined #nanoc
<bobthecow> :)
<ddfreyne> npm, bower, pip, ... are targeted for programming environments, rather than distros
churakova has joined #nanoc
<bobthecow> it's not a bad thing for a library with a dependency on a language to actually have a dependency on that language.
<bobthecow> `apt-get install ruby; gem install nanoc`
<ddfreyne> I understand what you mean.
<ddfreyne> OTOH, it would also be nice to automatically create a Debian/Arch/whatever package when a new nanoc version is released
<bobthecow> more and more libraries are taking the approach.
<bobthecow> i like what gulp's doing, in fact.
<bobthecow> they say "if your plugin does more than one thing, it should be more than one plugin"
<bobthecow> so they have a bajillion packages in npm.
<bobthecow> but each of 'em depends on exactly what they need.
<bobthecow> and everything keeps working, because they all can declare dependencies and even dependency versions.
<ddfreyne> Yeah, that's pretty much what nanoc 4.x is.
<bobthecow> yes, it took me a bit longer to set that up...
alerante has quit [Ping timeout: 264 seconds]
<bobthecow> but it would have taken even longer if every time i tried to use a new filter i had to run gulp and see that i was missing a dependency, then figure out what version of that dependency i should install, then go back and add it.
<bobthecow> with this, i just depend on the latest version of all my plugins, and let npm sort it all out.
<bobthecow> the problem with letting people install nanoc via apt is that it breaks down as soon as you have another plugin, or another dependency.
<bobthecow> because then you have to go find a tool you didn't even realize you needed to install that dependency.
<bobthecow> if you installed nanoc via rubygems, you already know nanoc lives in rubygems.
<ddfreyne> Yeah, that is true
<ddfreyne> I dobut that nanoc is very useful on Debian in its current form, because a lot of dependencies are missing anyway.
<bobthecow> i'm sure they are.
<bobthecow> unless they're building an epic "depend on everything ever" package.
<bobthecow> in which case, they can keep doing that, but do it with the nanoc plugins rather than the dependencies of the nanoc filters, and it'll be easier to maintain :)
relix has joined #nanoc
<ddfreyne> That's answering Daniel's remarks, unrelated to Debian packaging
<bobthecow> hey, you could add a `nanoc install` command that adds nanoc-foo to Gemfile and runs bundle install :)
<bobthecow> then quickstart is:
<bobthecow> nanoc create-site foo; cd foo; nanoc install haml kramdown sass
<ddfreyne> bobthecow: Not bad, but it's not that much more effort
<bobthecow> true.
<ddfreyne> I re-enabled Travis on nanoc 3.x to see how horrible it was.
<bobthecow> is there an equivalent to `npm install --save`?
<ddfreyne> I like Travis, but it's... unusable for nanoc.
<ddfreyne> bobthecow: What does that do?
<bobthecow> adds it to package.json and installs.
<bobthecow> because npm is gem+bundler, it has a command to do both.
<ddfreyne> The npm certification thing pissed me off royally a few days ago.
<bobthecow> yeah.
<ddfreyne> It is silly that we need so many different ways of packaging software...
<bobthecow> npm is still a bit annoying.
<bobthecow> i don't mind.
<ddfreyne> I rewrote a bunch of node.js code in Ruby today
<ddfreyne> I can't help not liking node
<bobthecow> :)
<ddfreyne> Actually, I can't help not liking JavaScript
<ddfreyne> I think it's a terrible language.
<bobthecow> you and i will have to agree to disagree on this one.
<ddfreyne> What do you like about it?
<ddfreyne> The latest build fails for two reasons
<ddfreyne> 1. safe level 4 is gone in Ruby 2.1
<ddfreyne> 2. There is a dependency on a Ruby 1.9+ gem
<tom[]> can nanoc produce a list of all the documents it outputs?
<bobthecow> tom[]: what do you mean?
<tom[]> nanoc outputs files
<bobthecow> yes, it does.
<tom[]> in any given run, nanoc is responsible for a number of output files. can it give me a list of them?
<bobthecow> just the ones it outputs during that run?
<bobthecow> or all files nanoc outputs?
<ddfreyne> tom[]: Nanoc::Item gives you #reps, and a Nanoc::ItemRep provides you with #raw_path to which you can give a snapshot, and you can get the snapshots using Nanoc::ItemRep#snapshots
<ddfreyne> It's not straightforward but the data is there
<tom[]> assuming "all" does not include intermediate temp files, then the latter
<ddfreyne> tom[]: where do you need it?
<tom[]> in a file i can use for .gitignore
<bobthecow> why not ignore the output folder itself?
<tom[]> it's not so simple in my setup
<tom[]> i have an old php web app. it has a big complex file tree. i use nanoc to produce output that mingles into that tree
<tom[]> for example. this page is a static file generated by nanoc: http://spinitron.com/doc/user-guide/schedule-shows/
<tom[]> this, otoh, is generated by a php script using a view that nanoc generated: http://spinitron.com/radio/playlist.php?station=kups&plid=3872&ptype=n
<bobthecow> that sounds like it's just asking for trouble :P
<ddfreyne> tom[]: Could you have the static content in a separate dir, and a PHP file that intercepts 404s and loads the right file?
<ddfreyne> (Just as a way to make things cleaner)
<bobthecow> i wouldn't even use 404s. i'd handle it at the apache or nginx level.
<ddfreyne> How come US radio stations have a 4-letter code?
<bobthecow> you can fairly easily set up the equivalent to rack's TryStatic in either of those.
<ddfreyne> (Something I've been wondering for a while)
<VitamineD> ddfreyne: some sort of legal immatriculation I believe
<tom[]> ddfreyne: they are not all 4 letter. radio callsigns aren't just american but it's required in the us that broadcasters identify themselves by their callsign
<travis-ci> [travis-ci] nanoc/nanoc/release-3.6.x 0a46abc Denis Defreyne: The build passed.
<bobthecow> ddfreyne: they don't all — https://en.wikipedia.org/wiki/Radio_call_sign#North_America
<tom[]> nanoc is also producing stylesheets and scripts that the php webapp is using
<bobthecow> tom[]: i'd do one of two things:
<tom[]> it's actually made things much more manageable than before
<bobthecow> i would probably set up a static data source with passthrough routes and put all the php app stuff in it.
<bobthecow> so that nanoc is actually "generating" those bits as well.
<tom[]> it's not really necessary to gitignore these static outputs, it just seems tidier
<bobthecow> then your whole output directory can be regenerated.
<bobthecow> alternatively, i'd do what ddfreyne said and have two "output" directories, one with the app, and one with nanoc's output.
<bobthecow> then set up apache or nginx to pull out of either of them.
<bobthecow> in fact, i've done the static data source thing several times.
<bobthecow> mixing revision controlled files with generated files is just asking for trouble though.
<tom[]> i prefer the static sources for a couple of reasons. 1. the autoloader would have to learn to look in two places. 2. some of the nanoc outputs are include()'ed. 3. it nice to keep app implementation out of the web server as much as possible
<tom[]> and, by the way, now that the updated version of spinitron is online, i'd like to say thanks for nanoc
<tom[]> thanks!
<tom[]> and for the support i've been given here
<ddfreyne> :)
<tom[]> there's a couple of techniques i ended up using that weren't like anything i could find with google
<tom[]> one was how to produce merged js or css asset files
<tom[]> i use an erb file to produce each client asset file. it has lines like this:
<tom[]> <%= @items['/assets/js/sidenav/'].compiled_content() %>
<ddfreyne> Yeah
<tom[]> so i can have a number of different merged/minified asset files all based on a common set of "sources", each of which can be generated by nanoc (e.g. from sass or coffee)
<tom[]> it's easy. and it was odd how many really complicated "solutions" to the same problem i found described on the www
<ddfreyne> I was playing with ideas to make this even cleaner a while ago, but none of them really work well.
<ddfreyne> I thought I had that written down somewhere, hm.
<tom[]> it's possibly worth documenting the idea
<tom[]> that's more dry than what i do. because i need special Rules for these erb asset files
<tom[]> so the description of what's going on is spread over two places
<ddfreyne> refresh, added a slightly different form
<ddfreyne> tom[]: You'd still have to have a rule for the invidiual parts, to make sure they're not routed
<ddfreyne> But that's expected.
<tom[]> actually, what i'm doing is a bit different
<tom[]> i want to explicitly list the sources in each asset file. it's not always as simple as throwing everything in a dir togetehr
<tom[]> the other thing i did was generalize this a little bit: https://github.com/aadlani/nanoc-toolbox/blob/master/lib/nanoc/toolbox/helpers/navigation.rb
<tom[]> that's what produces the sidenav in the documentation like this: http://spinitron.com/doc/special-topics/automation/access-control/
<GitHub22> [nanoc-core] ddfreyne pushed 1 new commit to master: http://git.io/DdzEag
<GitHub22> nanoc-core/master 0cb81eb Denis Defreyne: Do not freeze site so it can be modified in the preprocessor
<ddfreyne> tom[]: Yeah. I find it often very hard to come up with an elegant, DRY solution that fits everyone
<travis-ci> [travis-ci] nanoc/nanoc-core/master 0cb81eb Denis Defreyne: The build passed.
<tom[]> so echonest got bought by spotify. does soundcloud want to get bought?
<tom[]> by spotify?
<ddfreyne> tom[]: I can't really say much about that, but I do hope not :)
<GitHub194> [nanoc-core] ddfreyne pushed 1 new commit to master: http://git.io/gZTCjw
<GitHub194> nanoc-core/master 3d1a981 Denis Defreyne: Add Nanoc::Identifier.coerce
<ddfreyne> SoundCloud is not Spotify.
<tom[]> spotify is the enemy of all that is right and moral. i wouldn't say the same of soundcloud
<ddfreyne> good :)
<bobthecow> that's a strong opinion about spotify.
<bobthecow> so github switched to notices instead of comments for their irc bots.
<bobthecow> interesting.
<bobthecow> i like that better.
<tom[]> strong opinions about spotify are not uncommon
<ddfreyne> bobthecow: It is configurable
<bobthecow> ahh.
<ddfreyne> The previous commit makes the preprocessor useful again :)
<ddfreyne> Highest density of TODOs is 6 TODOs in 19 lines of code, heh
<ddfreyne> Apart from that, I like nanoc-core a lot more than nanoc 3.x from a tech point of view
<travis-ci> [travis-ci] nanoc/nanoc-core/master 3d1a981 Denis Defreyne: The build passed.
<tom[]> show's your a man with *plans*
antognolli has left #nanoc [#nanoc]
<ddfreyne> Hmm, Nanoc::Something.coerce(blah) to coerce blah to a Something, or Nanoc::Something.from(blah)? Which one do you prefer?
<ddfreyne> I have Nanoc::Identifier.coerce and Nanoc::Pattern.from, but they both do the same
churakova has quit [Ping timeout: 244 seconds]
<ddfreyne> (I think I like coerce more)
<bobthecow> or you could implement one of them in terms of the other
<ddfreyne> They do the same. It's just a naming convention
<ddfreyne> Hmm, Wikipedia says ”Implicit type conversion, also known as coercion”
alerante has joined #nanoc
<ddfreyne> Sleep, night!
<VitamineD> from is the intent, coerce is the method
relix has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]