bundler

> For exmaple I try hard to avoid using any non-standard libs with Ruby scripts so I can just use the system ruby, and don't have to ship a Gemfile and/or install any gems The ruby "story" for Gemfile dependencies for single-file scripts have gotten a BIT better since possibly last time you looked at it. It will of course necessarily involve installing gems still though. Ideally for your use case, I feel like you'd want to install them to a local (not system-default) location ... which is ordinarily possible with bundler, but oddly the maintainers seem to think it's an anti-use-case for inline bundler? https://github.com/rubygems/bundler/issues/7131. I dunno. Anyway, I put this here not to convince you, your decision is reasonable, but just other info for other readers.

It'll be here soon enough and it'll be interesting to see how it's handled, especially as the parties pushing for change tend to apply pressure as a group to those in authority (in our tech world, project leaders and moderators, but beyond it's appeals to universities or the media…) and flag/downvote (or worse) against those who show any dissent. The Opal project's little kerfuffle[0] a while back comes to mind, and the subsequent adoption by several Ruby projects of the Contributor Covenant[1] (of which, it never seems to be applied to its supporters - maybe that's just me being cynical). It convinced me that the best way to go is no code of conduct (I favour the delightfully named NCoC[2]) for most projects. [0] https://github.com/opal/opal/issues/941 [1] https://github.com/bundler/bundler/issues/3444 [2] https://github.com/domgetter/NC

I've not used Berkshelf, but I suspect your problems were related to Chef and the fact that they've built their own dependency system that also interacts with Bundler/RubyGems. Anecdotally, my company has used Ruby since around 2004, and Bundler since its first release, and we never had any issues. That doesn't mean nobody has ever had any issues (clearly! [2]), but it generally seems like Ruby package management is a solved problem, and that it would be a good model for any dependency system to use. Bundler does have one feature (or misfeature) that Russ Cox criticizes: "bundle install some_gem" can cause unrelated gems' minor (or maybe it's minor) versions to be upgraded even if you don't tell it to. I've never liked that, and would much prefer to use "bundler update" to perform explicit upgrades. But I don't think that behaviour is at

Use Ruby. It doesn't change much from version to version, thank God. I curse python every time I have to install a package. Nothing Just Works. If you install just one gem, bundler, you can get dependency management in a one-file script. Checkout Bundler Inline: https://github.com/bundler/bundler/blob/master/lib/bundler/i...

You weren't accused of "making a joke about racism". He posted the part of the CoC [0] that he believed you to have violated. He then gave you a 24-hour-block because your remark "counts as doubling down" on what he originally accused you of. I guess he didn't appreciate you implying that the CoC is a bunch of facile garbage. [0] https://github.com/bundler/bundler/pull/5808#issuecomment-38...

Yeah, sorry, I will try to make a long story short. For years I've had Bundler set to just run jobs equal to the number of cores on my system. However, I noticed it was running one less so I assumed I was doing something wrong. After hours of banging my head against the wall, I finally found that it Bundler subtracts 1 from the number of jobs you pass to it, but this behavior has been removed from master (for eventual 2.x branch). A bit irate, I engaged in the following exchange w/ Andre, in which he accused me of violating their CoC for posting a bit of a kneejerk comment, which I apologized for, but questioned what I possibly could've violated in the CoC, in the process making a wisecrack about the ridiculous term in it about "making casual references to slavery or indentured servitude." Anyway, if you really want to dig in, here's the

That's bundler boilerplate, totally verbatim: https://github.com/bundler/bundler/blob/master/lib/bundler/t...

Related: how bundler deals with it: https://github.com/bundler/bundler/blob/master/lib/bundler/d...

> I don't know if it's the same with Guix but in NixOS it's just a matter of running `bundix` and all the Gemfile.lock dependencies are converted to a nix expression. I'm glad to hear that the infrastructure is working for you. There are, admittedly, some kinks on master, though I have a PR to make things much, much more robust: https://github.com/NixOS/nixpkgs/pull/8612 Unfortunately, while Bundler is generally a great, useful piece of software, there are aspects of its design that make it very difficult - borderline antithetical - to cooperate with packaging; if you look at the commit message in the above PR, you can see a thorough description of the challenges. I have an open PR for Bundler to try to make things a bit more amenable, and recently got the thumbs up with respect to the general idea: https://github.com/bundler/bundler/pull

As a follow up, this was posted not too long afterwards: https://github.com/bundler/bundler/issues/3436 tl;dr, there's a bug where a CoC is created even if you opt-out.

Bundler's "condescension" was a real error message, albeit a terse one. I expanded it 18 days ago. If you think it's still condescending, please suggest a better way of phrasing the error. https://github.com/carlhuda/bundler/commit/abdc6374bd18488d0...

That also confused me. It is in the docs but not in the code yet (see: https://github.com/carlhuda/bundler/issues/1401 )