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