<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.
<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 :)
<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
<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.
<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[]>
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.