A discussion on Berkshelf worlfklow

gistfile1.irclog

<someara>   moin
[08:54:05] <maruq>	 gkarekinian: haha, probably.
[08:54:20] <maruq>	 gkarekinian: joining for the "how to cook good" chat?
[08:54:37] <maruq>	 someara: guten abend!
[08:54:42] <gkarekinian>	 Sure
[08:55:00] <gkarekinian>	 "How to avoid burning all your pans and pots"
[08:55:23] <someara>	 danke
[08:55:24] <maruq>	 haha!
[08:55:49] <maruq>	 someara: do you speak ze German, or just know the basics?
[08:55:58] <someara>	 just the basics
[08:56:56] Cope	 waves
[08:57:01] <Cope>	 ohai someara
[08:57:03] <someara>	 ein bier bitte
[08:57:07] <someara>	 zwei bier bitte
[08:57:15] <someara>	 drei bier bitte
[08:57:15] <gkarekinian>	 haha
[08:57:18] <maruq>	 someara: nice. So you have enough German to survive in Berlin ;)
[08:57:19] <gkarekinian>	 Hey everyone
[08:57:22] <someara>	 yep!
[08:57:32] Cope	 is in Berlin 11th-13th June
[08:57:43] <maruq>	 Cope: hey.
[08:57:49] <maruq>	 Cope: what are you here for?
[08:57:52] <gkarekinian>	 Nice
[08:58:19] <maruq>	 Cope: gkarekinian & I are Berlin based ;)
[08:58:38] <Cope>	 Ich bin nicht ein Berliner
[08:58:48] <Cope>	 nicht so!
[08:58:56] <maruq>	 haha
[08:59:51] <Cope>	 Wir können was trinken gehen oder so.
[08:59:54] <maruq>	 well, we've corrupted the Berkshelf channel with our poor German. My work here is done!
[09:00:07] <gkarekinian>	 :D
[09:00:16] <maruq>	 Cope: sounds good
[09:00:37] <Cope>	 dude it really doesn't; I can just about write pidgin german - I surely can't speak it ;))
[09:00:37] <simonmcc_>	 hey
[09:00:37] 	 Kiall (~kiall@kohana/developer/kiall) joined the channel.
[09:01:02] <Cope>	 ohai simonmcc_
[09:01:12] <simonmcc_>	 hey Cope
[09:01:23] <Cope>	 so - afraid I can only keep an eye on chat - I have to teach a class for 90 mins
[09:01:33] <someara>	 righto
[09:01:36] <someara>	 jedi4ever I believe had some berkshelf questions
[09:01:45] <maruq>	 all good
[09:02:03] <maruq>	 someara: yep. I think sascha_d was wanting to join too?
[09:02:13] <sascha_d>	 ohai!
[09:02:15] <sascha_d>	 it's that time
[09:02:20] <sascha_d>	 I had my timezone backward
[09:02:22] <Cope>	 ohai sascha_d ")
[09:02:28] <maruq>	 sascha_d: howdy!
[09:02:38] <gkarekinian>	 Hey
[09:03:11] <sascha_d>	 I want to observe this conversation as I do prefer Berkshelf, but it's not because I've made an informed choice except that Berks seemed to be more mature when I was picking a workflow tool
[09:03:57] 	 ssd7 (~ssd@64.187.170.247) joined the channel.
[09:04:16] <maruq>	 Similar, except I picked up Librarian before Berks was around. Have only toyed with Berks
[09:04:31] <someara>	 I guess I'll wait for patrick before I start yammering
[09:04:47] <maruq>	 someara: cool. seems fair as it was him that asked ;)
[09:04:59] <someara>	 its probably too early for reset or ivey to chime in
[09:05:06] <sascha_d>	 I also want to hear about the rvm/rbenv thought's he has
[09:05:30] <sascha_d>	 I have a fresh mbp here waiting for toolchain provisioning and admit I'm torn on what I want to do
[09:05:33] <gkarekinian>	 Same here, I've been using Librarian for a while now, I gave Berkshelf a try a couple weeks ago and I found it overly complicated
[09:05:50] <sascha_d>	 I built me a nice omnibus toolchain yesterday but am wondering how sustainable it is
[09:06:10] <simonmcc_>	 sascha_d: I think that was just a comparison? (rbenv/rvm cf Berkshelf
[09:06:35] <maruq>	 sascha_d: didn't you write the articles on the toolchains?
[09:06:46] <sascha_d>	 right, but the talk around it might help me clarify thoughts
[09:06:52] <maruq>	 okay.
[09:06:55] <sascha_d>	 I did write those blog posts and I have another one coming
[09:06:57] <simonmcc_>	 Do people really like the omnibus builds?  I'm not a fan - I now rely on OpsCode to keep all the bits they bundled up to date ;-/
[09:07:36] <sascha_d>	 But right now my thoughts on toolchains are: there's more than one way to do it, you should pick one and do what works for your and possibly your org.
[09:07:43] <maruq>	 I must admit I'm torn too… would be keen to see what you go with.
[09:07:48] <gkarekinian>	 I like it, now instead of things breaking because of RubyGems and dependency hell it breaks because someone fucked up
[09:07:48] <sascha_d>	 I have opinions on toolchaining, but the change
[09:08:12] <sascha_d>	 but they change
[09:08:29] <maruq>	 gkarekinian: someone fucked up = they forgot they metadata / didn't update it?
[09:08:56] <sascha_d>	 also something else I've learned is that I've leveled up somewhere in the last year on how I deal with dependency problems and understanding bundler and ruby and stuff.  And it's hard for me to have opinions based on inexperience now.
[09:08:59] <maruq>	 sascha_d: yep, keep it flexible, so you can swap parts out ;)
[09:09:07] <gkarekinian>	 maruq: I meant "someone fucked up" as in fucking up the release of the Omnibus Chef client version
[09:09:20] <BryanWB_>	 yoyo berkshelfers
[09:09:30] <someara>	 I just pinged patrick on the twitters...
[09:09:32] <maruq>	 hey BryanWB_
[09:09:38] <BryanWB_>	 hi maruq
[09:09:44] <gkarekinian>	 When we used to use the Chef gem and a global Ruby things would just break as soon as another gem was installed, pretty much
[09:09:48] <jedi4ever>	 someara: alive yo - got caught up
[09:09:50] <BryanWB_>	 gem all the things
[09:09:53] <gkarekinian>	 json hell, and so on
[09:09:54] BryanWB_	 ducks
[09:09:58] <someara>	 there he is!
[09:10:10] <gkarekinian>	 Hey Bryan, Patrick, everyone :)
[09:10:13] <maruq>	 haha
[09:10:27] <jedi4ever>	 howdy gang!
[09:10:33] <sascha_d>	 by way Berkshelfers, we're having a party in the berkshelf channel this morning :)
[09:10:42] <someara>	 sorry about irc... a hangout would have been better but I'm at a customer site behind a thousand proxies
[09:10:53] <maruq>	 it's okay, sascha_d said she's bringing popcorn ;)
[09:10:58] <simonmcc_>	 yum
[09:11:12] <sascha_d>	 It's only 9am here, so I'm actually bringing blueberries and oatmeal
[09:11:38] <maruq>	 sascha_d: sounds good to me ;)
[09:12:08] <maruq>	 okay, should we try and structure this somehow?
[09:12:32] <jedi4ever>	 take it away maruq
[09:12:34] <someara>	 so I guess patrick is confused about why berkshelf exists vs librarian, and we've starting making analogies to rvm/rbenv/things to try and figure it out
[09:12:44] <maruq>	 I guess jedi4ever what were your main questions around this?
[09:12:59] <jedi4ever>	 ok - i'll kick of the movie with my "issue"
[09:13:16] <jedi4ever>	 I understand both tools to be like a Gemfile for cookbooks
[09:13:24] <gkarekinian>	 Yes
[09:13:28] <sascha_d>	 I am logging this irc chat btw and may cite it in future blog posts about toolchains :)
[09:13:30] <jedi4ever>	 they both work what they are supposed to do
[09:13:53] <jedi4ever>	 with librarian-chef there is a standalone cookbooks dir per project
[09:14:13] <jedi4ever>	 but with berkshelf- by default this cookbook 'cache' is central in .berkshelf
[09:14:20] <maruq>	 jedi4ever: yep, "cookbooks" = reps, "site-cookbooks" = do what you want
[09:14:31] <maruq>	 *deps. damn auto-correct
[09:15:00] <someara>	 so the question is : why the cache vs managing a cookbooks dir?
[09:15:06] <jedi4ever>	 so I'm use to work in gemsets,
[09:15:24] <jedi4ever>	 for my different project so one gem update doesn't interfere with another project
[09:15:46] <jedi4ever>	 this keeps me from breaking projects for customers when I don't want them to update
[09:15:57] <jedi4ever>	 with librarian I could that similar to gemsets
[09:16:19] <jedi4ever>	 I rsync my cookbooks for run with chef-solo per customer
[09:16:35] <jedi4ever>	 so this is probably a slightly unusual use case of the cookbooks
[09:16:42] <someara>	 not at all
[09:17:03] <maruq>	 makes sense
[09:17:04] <jedi4ever>	 so if haven't touch customer one's project with a librarian update , it will always give the same versions
[09:17:26] <jedi4ever>	 but with the shared 'cache' from berkshelf, doing a berks update my influence another customer
[09:17:38] <someara>	 erm
[09:17:41] <jedi4ever>	 my workaround would be setting the BERKSHELF var per customer
[09:17:52] <gkarekinian>	 We have the same workflow and the same issue then
[09:18:08] <jedi4ever>	 this is my first issue
[09:18:21] <sascha_d>	 @jedi4ever would you say you're missing the lockfile functionality then?
[09:18:30] <someara>	 just fyi you may be hitting an outstanding bug in berks ;)
[09:18:37] <maruq>	 I don't know enough about berks, but my understanding was the cache was for keeping central store, and it kept versions?
[09:18:52] <someara>	 can I take a crack at laying down some conceptual foundation?
[09:19:01] <jedi4ever>	 sure!
[09:19:01] <maruq>	 someara: that'd be great
[09:19:12] <someara>	 so starting at the top and working down (a very berkshelfy thing to do btw)...
[09:19:48] <BryanWB_>	 maybe i am missing something but wouldn't having a Berksfile and Berksfile.lock per customer give Patrick what he is looking for
[09:19:49] <BryanWB_>	 ?
[09:19:56] <someara>	 first thing to understand is that berkshelf is opinionated about workflow and encourages a design pattern
[09:20:20] <sascha_d>	 @BryanWB_I was thinking that, but keeping in mind that actual lock functionality isn't until 2.0 right? I have it in my beta install.
[09:20:24] <someara>	 this design pattern is the "application cookbook" design pattern, where you utilize other cookbooks as libraries
[09:20:41] <someara>	 you never use roles, and databags are used grudgingly
[09:20:48] <BryanWB_>	 sascha_d: hasn't berksfile.lock been there sinc ehte beginning?
[09:21:03] <sascha_d>	 @BryanWB_ yes but it didn't really lock anything
[09:21:15] <sascha_d>	 now in 2.0 it complains if you mess with versions
[09:21:16] <BryanWB_>	 sascha_d: oh, color me surprised
[09:21:32] <BryanWB_>	 i thot it did the same thing as Gemfile.lock
[09:21:34] <sascha_d>	 @ivey may be able to break in here with commentary too
[09:21:55] <jedi4ever>	 someara:  please continue :)
[09:21:58] <someara>	 so, the "classic" chef workflow is to have chef-repos per "project", where a project typically fits in on chef-server api endpoint
[09:22:03] <someara>	 so
[09:22:33] <someara>	 infrastructure-1/cookbooks infrastructure-2/cookbooks infrastructure-3/cookbooks
[09:22:43] <someara>	 also roles, databags, etc subdirs for each
[09:22:54] <someara>	 often there will be a .chef/knife.rb in each of those
[09:23:21] <someara>	 and you switch between these projects with a directory based workflow... cd project1 ; cd ../project2
[09:23:38] <jedi4ever>	 yup, pretty much how I use it currently
[09:23:42] <someara>	 right.
[09:23:44] <maruq>	 someara: and usually an .rvmrc to switch gemsets
[09:23:50] <someara>	 so
[09:23:55] <someara>	 berkshelf does away with that
[09:24:06] <someara>	 now your project is just the cookbook
[09:24:34] <someara>	 the cookbook being a verson controlled software artifact, on par with a language runtime library like a rubygem or python module
[09:25:06] <someara>	 so I can do a "berks cookbook myface ; cd myface ; vagrant up"
[09:25:28] <maruq>	 someara: so company_x_appserver = new cookbook with a few depends + attributes?
[09:25:39] <someara>	 and if I need to utilize, say, openssl, git, windows, whatever cookbooks as libraries, all I have to do is add them into the metadata
[09:25:48] <maruq>	 someara: and company_x_dbserver = another cookbook?
[09:25:52] <someara>	 yep
[09:26:10] <someara>	 the idea is that the berkshelf is the same thing as a gem cache
[09:26:15] <maruq>	 hmm… interesting
[09:26:21] <someara>	 so you can have multiple versions of the same cookbook in the cache
[09:26:37] <someara>	 just like you do with ruby gems
[09:27:04] <jedi4ever>	 q: if you depend for p1 on jedi4ever/master of cookbook and for p2 on opscode/master of a cookbook
[09:27:07] <simonmcc_>	 @someara so how do you see that working with a multi role environment (proxy, app, db) - with shared core, or is that just plain against your workflow?
[09:27:13] <maruq>	 so project_x depends on postgresl cookbook 2.0, project_y depends on postgresql cookbook 2.1, what happens?
[09:27:46] <gkarekinian>	 I think I'm more confused now than I was before
[09:27:50] <jedi4ever>	 +1 for simonmcc_ question
[09:28:15] <someara>	 so you'd specify postgresql "= 2.0" in project_x's metadata, and postgresql "= 2.0" in project_y's metadata
[09:28:19] <someara>	 just like a gemspec
[09:28:50] <someara>	 the berkshelf would have both .berkshelf/cookbooks/postgresql-2.0 and cookbooks/postgreql-2.1
[09:28:56] <maruq>	 okay, makes sense
[09:29:00] <Cope>	 jedi4ever: this is what I was alluding to on twitter
[09:29:14] <Cope>	 the problem you want to solve is the proble bundler solves for rubygems
[09:29:20] <Cope>	 berkshelf is just bundler for cookbooks
[09:29:43] <someara>	 cd project_x ; vagrant up ; berkshelf installs pg-2.0 into your vagrant vm
[09:29:55] <jedi4ever>	 but if you don't rely on a specific version but on master, it will become from 2 different projects <cookbooname>-master
[09:29:59] <someara>	 cd ../project_y ; vagrant up ; berkshelf installs pg-2.1
[09:30:23] <someara>	 jedi4ever ideally, you want to realy in "artifacts" installed on your chef-server, or from the community site.
[09:30:30] <jedi4ever>	 so you assume that the source of a cookbook comes from the same origin
[09:30:32] <someara>	 installing from git is discouraged but tolerated
[09:30:55] <someara>	 yep. just like if you wanted to use the nokogiri gem, you'd expect it to come from rubygems
[09:31:06] <jedi4ever>	 someara: I'd love to, but company X has it's own version, company Y it's other version
[09:31:07] <someara>	 and if you wanted to hack on it, you can do a local path, or your git branch
[09:31:18] <someara>	 well that's a namespacing problem
[09:31:39] <jedi4ever>	 so it would be solved with berkshelf namespacing it using the origin as well
[09:31:41] <someara>	 berkshelf encourages the "don't fork, contribute upstrea!" model
[09:31:58] <BryanWB_>	 but namespaces would be useful 4 us consultants
[09:32:02] <jedi4ever>	 someara: with all respect, try find a decent not forked version :)
[09:32:04] <maruq>	 someara: so the rubygems.org for berkshelf is the community page?
[09:32:13] Cope	 nods
[09:32:21] <someara>	 company_x_java and company_y_java are neither the "java" cookbook
[09:32:23] <Cope>	 you have a canonical source - community
[09:32:28] <someara>	 maruq yep
[09:32:38] <Cope>	 and you can then 'wrap' that with your own modifications
[09:32:51] Cope	 back to training
[09:32:52] <someara>	 we (opscode) need to clean out all the cruft from the community site, admittedly
[09:33:01] <someara>	 still trying to figure out what to do about that
[09:33:13] <jedi4ever>	 as much as I'm pro - I believe in practice/theory
[09:33:22] <maruq>	 someara: don't worry, we all need to clean out cruft from our repos ;)
[09:33:25] <someara>	 but the namespacing thing is why rubygems has all the cute names
[09:33:36] <someara>	 nokogiri could easily be named "libxml"
[09:33:46] <jtimberman>	 man i wasn't in here. is this logged? I want to hear someara's words
[09:33:46] <someara>	 amirite
[09:33:52] <jedi4ever>	 even with a non forked version - consider my own fork for contributing to a cookbook vs an upstream - same namespacing problem
[09:33:59] <maruq>	 jtimberman: yep, sascha_d's logging it
[09:34:22] <jtimberman>	 wewt
[09:34:45] <someara>	 jedi4ever so lets say you wanted an openldap cookbook... and the one on the community site is old and crufty and unuseful
[09:35:15] <someara>	 you'd write your own with a different namespace, unfortunately
[09:35:33] <someara>	 and then bug josh to take over the namespace =)
[09:35:45] <maruq>	 haha
[09:36:05] <maruq>	 so there's no way to have berkshelf append source to it if it's not opscodes?
[09:36:07] <jedi4ever>	 now there's a business model - either for taking over all namespaces
[09:36:18] <jedi4ever>	 or you attribute it to the highest bidder :)
[09:36:33] <simonmcc_>	 cookbook squatting
[09:36:42] <someara>	 maruq opscode doesn't own all the cookbooks on the community site
[09:36:50] <sascha_d>	 I'm just catching up here, but for the record, I install from both github and my client's Enterprise Github
[09:37:14] <sascha_d>	 it's also possible to specify a path argument for local dev when I'm hacking on a community cookbook to make it work
[09:37:30] <sascha_d>	 the diff is that I also try to contribute back upstream once things actually work
[09:37:35] <jedi4ever>	 sascha_d: true, wondering if that overtakes the .berkshelf cache on install?
[09:37:35] <simonmcc_>	 sascha_d: +1 (github & internal gitolite, stuff we don't "care" about comes from the community)
[09:38:10] <sascha_d>	 it's also also possible to specify both branches and tags in the Berksfile
[09:38:33] <maruq>	 someara: sorry, I meant if it comes from opscode-cookbooks, then it's just "postgresql". If it comes from my repo, then it's markbate_postgresql
[09:38:34] <sascha_d>	 and create "groups" of cookbooks as well
[09:38:55] <jedi4ever>	 ok let's I am using the community cookbook and there is no fork
[09:38:59] <someara>	 so in my workflow, I often end up with a cookbook directory with a Berksfile that points to 4 or 5 local paths for cookbooks that I've forked and cloned from the internets
[09:39:11] <sascha_d>	 me too
[09:39:23] <jedi4ever>	 if I have p1 , and point it to a local path and do a berkshelf install , will it change all other projects to my local one
[09:39:25] <someara>	 and before I publish my cookbook, I'd want to patch and send those 4 or 5 cookbooks upstream
[09:39:30] <someara>	 so I can delete the Berksfile
[09:39:52] <someara>	 jedi4ever wat
[09:40:02] <maruq>	 someara: but then what if a coworker doesn't have that set?
[09:40:26] <gkarekinian>	 But it can take a while for your patches to get merged, if ever
[09:40:31] <someara>	 maruq then you'd want to switch to git and push some shas
[09:40:44] <jtimberman>	 yeah, re cookbook site, we only have 140ish of the 950+ cookbooks
[09:40:45] <someara>	 you can also use your chef-server as a cookbook artifcat repo
[09:40:55] <someara>	 instead of the community site
[09:41:00] <gkarekinian>	 Some people don't really look at pull requests on their cookbook, because the current version works for them
[09:41:19] <sascha_d>	 @gkarekinian then you DO fork it and become the dominant authority
[09:41:32] <sascha_d>	 see Miah's redis cookbook for that real life example :)
[09:41:37] <jtimberman>	 gkarekinian: we don't look at all the pull requests because many don't have an associated COOK ticket ;)
[09:41:41] <gkarekinian>	 Yeah, I guess
[09:41:52] <someara>	 jedi4ever I see what you're saying... if I point my p1/Berksfile to cookbook "yum" => "/path/to/yum" and do a berks install
[09:41:56] <someara>	 p2 will use that yum
[09:42:17] <gkarekinian>	 jtimberman: I didn't mean cookbooks maintained by Opscode, you're pretty fast nowadays when there's a JIRA ticket :)
[09:42:20] <jedi4ever>	 someara: extra namespacing of origin would solve my problem
[09:42:20] <someara>	 right?
[09:42:26] <jedi4ever>	 someara: correct
[09:42:28] <someara>	 okay
[09:42:45] <someara>	 well that's because you're working on yum-0.1.0
[09:42:49] <someara>	 that's actually by design
[09:42:53] <jedi4ever>	 jtimberman: the COOK is just a throw if over the wall trick :)
[09:42:55] <someara>	 you'd want to bump the version number
[09:43:17] <someara>	 for example, I have my line cookbook, and I just re-implemented a library so its not borked
[09:43:23] <jedi4ever>	 someara: if you're not the maintainer , it's not up to you to update the version number
[09:43:25] <someara>	 and I'd want all my projects to use that
[09:44:38] <jedi4ever>	 suppose I just am working on a cookbook enhancement for upstream pull request
[09:44:39] <someara>	 jedi4ever true. but if you're bugfixing for yum-0.1.0 would you not want it to be picked up by all the projects? if you're feature enhancing, then you'd want to either "ghetto bump" it, or use a git sha
[09:45:02] <jtimberman>	 jedi4ever: well, we basically have one person on COOK full time. There's 140 cookbooks.
[09:45:03] <someara>	 also semver is part of the opinionation
[09:45:27] <jtimberman>	 And frankly, everyone wants every cookbook to support all their use cases and bikeshed colors.
[09:45:58] <maruq>	 jtimberman: I guess you're a big fan of the application cookbook approach then ;)
[09:46:00] <jedi4ever>	 someara: but if I have 10 projects relying on that 1 cookbook I'm changing, I'll have to set sha-s for everyone one? That's inverting the problem
[09:46:05] <someara>	 jedi4ever the buggest concept is that a cookbook is an immutable artifact.
[09:46:18] <someara>	 so like... would you go into your gemset and start hacking on a ruby lib?
[09:46:18] <jtimberman>	 to bring this to berkshelf, sometimes it's totally apropos to "fork" a cookbook in that you make a "wrapper" for it that supports the special use case.
[09:46:28] <someara>	 or would you fork and clone the gem, and re-install it
[09:46:54] <jedi4ever>	 jtimberman: I was trolling you - ignore me
[09:47:08] <jedi4ever>	 someara: trying to grok this analogy
[09:47:49] <sascha_d>	 Also like to throw in a giant kudos to @BryanWB_ and his rewind gem which has saved me from egregious cookbook forking many times
[09:47:51] <jedi4ever>	 someara: with my gemsets per project, I don't interphere the other projects
[09:48:10] BryanWB_	 blushes
[09:48:21] <maruq>	 someara: I guess fork, rename it (eg. maruq_cookbookx), then reinstall is the new intended approach?
[09:49:17] <someara>	 ya
[09:49:27] <sascha_d>	 when I need to extend or rewind a community cookbook (I did this for syslog and yum), I create a client_cookbook name and wrap the extending functionality in there, if it's not something I can/need/want to push upstream
[09:49:54] <someara>	 jedi4ever okay when I want to work on veewee, I fork, clone, hack, build, gem install and test, right?
[09:49:56] <maruq>	 sascha_d: makes sense
[09:50:24] <jedi4ever>	 someara: euh right
[09:50:38] <jedi4ever>	 but I see no need to change the version there
[09:50:39] <sascha_d>	 my client_yum includes the community cookbook and then creates several internal repos. The community cookbook now includes a priority attribute for yum repos that I pushed back upstream.
[09:50:40] <jtimberman>	 jedi4ever: i know its ok :)
[09:50:47] <someara>	 so now I have a veewee-0.3.7 in my ruby environment that is my hacked up version
[09:50:50] <jtimberman>	 but, the casual reader might not know :D
[09:50:51] <someara>	 with the same number
[09:50:55] <jedi4ever>	 correct
[09:51:21] <someara>	 okay so if I had one project that needed the new veewee, and another project that needed the old veewee, what would I do
[09:51:36] <jtimberman>	 fwiw, this "overlay" stuff is what site-cookbooks was kind of all about
[09:51:51] <jtimberman>	 primarily for templates and files so you could replace with your own
[09:51:59] <sascha_d>	 @jtimberman I miss that mergey goodness
[09:52:00] <maruq>	 jtimberman: I used to call it "augmenting", but yep, same idea
[09:52:18] <jedi4ever>	 someara: change the version number or if you don't care master … but it's a subtle difference:
[09:52:26] <someara>	 aha
[09:52:38] <jtimberman>	 it's still there!
[09:52:41] <jedi4ever>	 if I do a bundle install in my new to hack gem, I'm not changing the other projects on my laptop yet
[09:53:01] <jedi4ever>	 so if I do an rsync of those projects, they still get the latest synched version
[09:53:25] <jedi4ever>	 only my new while I'm hacking gemset/test project has the latest code
[09:53:32] <someara>	 if the hacked version is in your ruby environment, you bet bundler will use it
[09:53:43] <jedi4ever>	 not with rvm gemsets
[09:53:49] <jtimberman>	 sascha_d: the shadowing feature, which overlays a file of the same name (and maybe only certain files) will throw a warning.
[09:53:56] <jedi4ever>	 I have gemsets per projects
[09:54:02] <someara>	 if you wanted gemsets
[09:54:24] <someara>	 you'd move back to the chef-repo/cookbooks model and do a berks install --path chef-repo2/cookbooks
[09:54:33] <someara>	 that's the difference
[09:55:10] <jedi4ever>	 that is indeed a solution , or a namespacing in berkshelf, based on origin
[09:55:16] <someara>	 yep
[09:55:41] <jedi4ever>	 then i don't have to do anything special, works the same - everybody happy :)
[09:55:50] <maruq>	 haha cool
[09:56:03] <someara>	 so native berks == system ruby or rbenv && berks with vendoring == rvm with vemsets
[09:56:10] <someara>	 s/vemsets/gemsets/
[09:56:17] <sascha_d>	 For anyone new to the workflow ideas in here, I definitely recommend watching Jamie's Chefconf talk on "The Berkshelf Way" which is a workflow discussion, not tool use itself.  I've seen it once at the chefconf and once at the Bay meetup group and it's super.
[09:57:15] <jedi4ever>	 someara: so I'd go somewhere in between with berks + namespacing origin
[09:57:21] <maruq>	 http://www.youtube.com/watch?v=hYt0E84kYUI
[09:57:28] <maruq>	 ^^ that's the talk
[09:59:28] <maruq>	 cool, was there any more issues / questions, or did we all have the same general problem?
[09:59:38] <Cope>	 jedi4ever: what does rvm gemsets give you that bundler doesn't give you?
[09:59:45] <maruq>	 (ie. a misunderstanding of the workflow)
[10:00:44] <someara>	 origin namespacing would solve a lot of problems
[10:00:44] <jedi4ever>	 Cope: if you install multiple projects in system ruby, it might take a different version of f.i. net-ssh because another project installed
[10:01:16] <jedi4ever>	 they I manage it , is per project so I start from a clean install, so I know the version of my depedencies (without hard specifying it)
[10:01:32] <Cope>	 probably veering off topic, but I feel it's kinda relevant, but I think bundler gives you that without gemsets
[10:01:53] <Cope>	 full disclosure: I think rvm gemsets are a nasty hack
[10:01:55] <jedi4ever>	 if all versions are specifically and correctly specified
[10:02:00] <gkarekinian>	 Yeah, you can isolate your environment with Bundler, --path
[10:02:08] <someara>	 Cope there's still the "top level" though... so you can cd p1, bundle exec whatever, cd p2, bundle exec whatever, and everything is kosher
[10:02:21] <Cope>	 right
[10:02:31] <someara>	 but when you want to "knife this" or "knife that" from outside a project directory, suddenly gemsets would be handy
[10:02:41] <jedi4ever>	 before rvm, i have a RUBYGEMPATH environment per customer
[10:02:41] <someara>	 because json
[10:02:43] <Cope>	 agree
[10:02:53] <jedi4ever>	 we all know the horror of shared DLL's
[10:02:55] <sascha_d>	 @Cope @jedi4ever please continue with this off topic discussion. I approve of all toolchain debates/discussions
[10:02:57] <jedi4ever>	 > that
[10:03:06] Cope	 back to training :)
[10:03:19] <someara>	 hey guys I gotta run. I'll be back on in an hour or two
[10:03:25] <someara>	 later!
[10:03:28] <jedi4ever>	 someara: thx for the insights
[10:03:35] <someara>	 any time
[10:03:35] <jedi4ever>	 sascha_d: thx for the popcorn :D
[10:03:48] <maruq>	 someara: thanks heaps. I understand a lot more now ;)
[10:04:52] <jedi4ever>	 by the way, my son found it übercool, that I was looking at a page of riotgames :)
[10:05:04] <jedi4ever>	 bumped my dad-credits - so thx #berkshelf
[10:05:09] <maruq>	 jedi4ever, sascha_d: so any thoughts on this toolchain then? can we remove rvm? ;)
[10:05:20] <sascha_d>	 I still am rather attached to rvm
[10:05:30] <sascha_d>	 though I pretty much stick with one ruby
[10:05:41] <sascha_d>	 and bundled dirs work for me most of the time
[10:06:01] <jedi4ever>	 maruq: why would you think we can remove rvm?
[10:06:03] <sascha_d>	 and I'm in a sweet spot lately where I don't have any egregious dep collisions
[10:06:07] <maruq>	 sascha_d: yeah, I generally stick to the latest & use gemsets. I always get into messes with gemsets though
[10:07:08] <maruq>	 jedi4ever: it was a joke. I realise some of us need to switch rubies ;)
[10:07:23] <jedi4ever>	 maruq: we could start the debate on rubyenv :)
[10:07:37] <maruq>	 maybe one day Apple will the system ruby
[10:07:57] <jedi4ever>	 maruq: it will be the next thing they'll ditch after java :)
[10:08:04] <gkarekinian>	 <3 chruby
[10:08:26] <maruq>	 gkarekinian: I still need to play with chruby, but from what I've read, it looks nice
[10:08:26] <jedi4ever>	 gkarekinian: if only I could compile ruby to a binary :)
[10:08:50] <gkarekinian>	 It's 90 lines of bash, pretty much just sets env variables
[10:09:36] <jedi4ever>	 gotta run - thx y'all - enjoy the weekend!
[10:09:52] <maruq>	 jedi4ever: thanks, you too!
[10:09:53] <gkarekinian>	 I have to run too, have a good weekend everyone!
[10:12:56] <jtimberman>	 ok i was mistaken, site-cookbooks overlay *is* deprecated and it will warn on 'knife cookbook upload'
[10:13:16] <jtimberman>	 but it's not totally removed yet (perhaps chef 12, dunno)
[10:13:56] <maruq>	 jtimberman: I'll miss it.
[10:14:22] <maruq>	 used to use it a bit back in the 0.8/0.9 days
[10:14:33] <gkarekinian>	 Same here, but I don't miss it :D
[10:16:07] <maruq>	 alright, I'm going to have to call it a day too.
[10:16:18] <maruq>	 thanks all, was great to get more insight there.