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
<ddfreyne> jugglinmike: the .yaml file should contain a hash
<ddfreyne> jugglinmike: e.g. you cannot just put "[1,2,3]" in the .yaml file, but "data: [1,2,3]" works fine
<jugglinmike> ddfreyne: That's what I figured
<jugglinmike> And it's essentially what I did to provoke the second error I reported
<jugglinmike> (Is there some technical constraint that would prevent nanoc from working with yaml files that define arrays, by the way?)
pavelkunc has quit [Quit: Leaving.]
<jugglinmike> i.e. do you think I should try to patch it to work with arrays, ddfreyne?
<jugglinmike> in a pull request
<jugglinmike> Actually, now I'm wondering if I'm solving this problem in the wrong way.
<jugglinmike> I want to concatenate JavaScript files, so I'm adding .yaml content files that list the JavaScript files that should be concatenated, and then writing a custom filter to do the file reading and concatenation
<jugglinmike> I wonder if nanoc will be able to trace dependencies for this setup, though
<jugglinmike> depend_on !!
<bobthecow> jugglinmike: make the yaml files have an object with an array, rather than an array at the root.
bobthecow has left #nanoc ["Linkinus - http://linkinus.com"]
bobthecow has joined #nanoc
<jugglinmike> bobthecow: thanks!
<jugglinmike> bobthecow: I was thinking it might be nice to be able to define yaml content as "anonymous" arrays--does this seem inappropriate for nanoc?
<bobthecow> but how would you get it out of the item?
<jugglinmike> through numeric indices
<jugglinmike> bobthecow: I'm trying to generalize that pattern to a filter
<jugglinmike> "Concat"
<bobthecow> i did that.
<jugglinmike> aww man
<bobthecow> well, something like that.
<bobthecow> no, i haven't released it.
<bobthecow> and probably won't.
<bobthecow> so go for it :)(
<bobthecow> mine had a specific key, like that "scripts" above.
<bobthecow> so that you could have other metadata in it.
<bobthecow> things like that is_hidden.
<jugglinmike> bobthecow: Here's my work in progress: https://gist.github.com/jugglinmike/8393545
<jugglinmike> the item_pathname is incorrect, though
<jugglinmike> "the item_pathname method"*
<jugglinmike> content_filename
<bobthecow> when i did it i used nanoc identifiers (hence the /js/jquery/ above)
<bobthecow> since i figured that was most consistent with nanoc.
<bobthecow> re: your issue — as far as I know, :content_filename is an implementation detail of the filesystem and filesystem_unified data sources.
<bobthecow> that said, it's probably not a problem to rely on it for your filter, as almost everyone uses those data sources, at least for assets like you're dealing with.
<bobthecow> that's probably why the less filter uses it... sure, you could run into problems with, for example, my github projects data source. but why would i be running my github projects through a less filter?
<bobthecow> jugglinmike: ^
<jugglinmike> bobthecow: ahh
<jugglinmike> thanks!
<bobthecow> no problem.
jugglinmike has quit [Quit: Leaving.]
relix has joined #nanoc
pavelkunc has joined #nanoc
prxq has joined #nanoc
pavelkunc has quit [Quit: Leaving.]
pavelkunc has joined #nanoc
VitamineD has quit [Quit: VitamineD]
VitamineD has joined #nanoc
jugglinmike has joined #nanoc
alerante has quit []
pavelkunc has quit [Quit: Leaving.]
pavelkunc has joined #nanoc
VitamineD has quit [Ping timeout: 245 seconds]
relix has quit [Quit: Textual IRC Client: www.textualapp.com]
relix has joined #nanoc
VitamineD has joined #nanoc
pavelkunc has quit [Quit: Leaving.]
relix has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
pavelkunc has joined #nanoc
pavelkunc has quit [Quit: Leaving.]
relix has joined #nanoc
<jugglinmike> I have a general Ruby project management question--typing now
<jugglinmike> My project version controls the `Gemfile.lock` file, but I use `gem install` during development. This means bundler constantly updates the lock file, and git always lists the file as having unstaged changes
<jugglinmike> This is annoying--staging changes is always a hassle. I'm constantly picking around the changes to `Gemfile.lock` because I don't want to update the dependencies in production
<jugglinmike> I checked out some of the few Ruby-driven projects I'm familiar with (nanoc, ember.js), and they both version control `Gemfile` and `Gemfile.lock`
<jugglinmike> so I imagine their workflow is a little better
<jugglinmike> As far as I can tell, either (1) there is a different bundler command I should be using during development, or (2) I should add `Gemfile.lock` to my project's `.gitignore` file (and use `git add -f` to explicitly update it when I want to upgrade dependencies in my dev environment)
<jugglinmike> although neither of the two projects I mentioned take approach (2)
<jugglinmike> Can anyone tell me what I'm doing wrong?
<jugglinmike> oops, my bad. During development, I type `bundle install`--*that* command updates the `Gemfile.lock`
relix has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<bobthecow> jugglinmike: bundle install shouldn't update your gemfile.
<bobthecow> bundle update does.
<bobthecow> but bundle install should be installing exactly what the gemfile.lock says to install.
<bobthecow> what changes are you seeing?
<jugglinmike> bobthecow: I asked in bundler and learned that this is happening because my system has newer versions of some of these gems
<jugglinmike> I guess I need to downgrade them somehow
<bobthecow> i've never had that problem.
<bobthecow> i have tons of versions of things.
<bobthecow> and my lockfiles stay where they belong.
<jugglinmike> Maybe I'm misunderstanding, then. Here's what ddd told me in #bundler: "(05:19:53 PM) ddd: because if you bundle install and a newer version of a dep is used, it changes the written lock file"
<bobthecow> jugglinmike: maybe the older version has been pulled and is no longer available?
<jugglinmike> oh, you know what
<jugglinmike> I'm a dummy
<jugglinmike> It's that this Gemfile.lock is just way out-of-date
<bobthecow> that'll do it :)
<jugglinmike> This happened because our deployment environment doesn' t use it
<jugglinmike> So I'm not seeing version changes, but addition/deletion of gems
<bobthecow> oh. you should.
<bobthecow> that's why it's there.
<jugglinmike> yeah, I'm trying to fix things
<jugglinmike> but also understand how this works at the same time :)
<jugglinmike> Here's the last thing I don't understand about this project
<jugglinmike> I know understand that if I want to add a feature to this nanoc project that uses the uglify filter
<jugglinmike> I should run `gem update uglify_js` to make sure that the Gemfile.lock is updated with the latest Gem version, but the other gems are untouched
<bobthecow> no.
<bobthecow> bundle.
<bobthecow> always bundle.
<jugglinmike> ahh right right
<jugglinmike> sorry
<bobthecow> never type "gem"
<jugglinmike> I'm confusing the keywords
<jugglinmike> but I'm with you there
<jugglinmike> and I understand that, in production, I should run `bundle install --deployment` to grab the exact dependencies listed in the Gemfile.lock
<jugglinmike> but what I don't quite get
<jugglinmike> is how other developers would get my changes
<jugglinmike> the bundler documentation says not to use `--deployment` on development machines
<bobthecow> they would check out your project and run `bundle install`
<bobthecow> that's it.
<jugglinmike> oh
<jugglinmike> actually, yes
<bobthecow> bundle install uses the lockfile.
<jugglinmike> I was still operating under the confusion about that
<jugglinmike> thanks for your patience, bobthecow. I think I get it now :)
<bobthecow> :)
<bobthecow> "bundle update" changes things, "bundle install" just installs the locked version.
<bobthecow> assuming you have a lockfile.
<bobthecow> if you don't, it installs the latest versions that match your requirements.
<bobthecow> if your gemfile is done right, though, you should be able to `bundle update` any time, run your test suite, and commit the lockfile changes.
<bobthecow> anything that requires a specific version of a gem should use pessimistic versioning, everything else should use ~>
<jugglinmike> yeah, I'm going to fix this right now