04:44 <nakilon> https://stackoverflow.com/q/18022232/322020 I see someone asked it, but the answer does not suit my needs; I need a "namespace" have the methods of the same purpose, just an arbitrary number of it (it would mean "we can do the same operation in several ways", and the framework than uses them all), i.e. the namespacing purpose is to just split to be able to "take all methods of this specific purpose

04:44 <nakilon> "

06:03 <o0x1eef> You're looking for a pattern, not a framework - IMO.

06:05 <o0x1eef> I did it more or less the same as that stackoverflow post.

15:03 <nakilon> I mean I'm making a framework

15:03 <nakilon> that will be used via this pattern

17:17 <o0x1eef> Ah okay. That makes sense. But why doesn't that pattern work? You want something to automate it?

19:40 <nakilon> o0x1eef: I think my code above is more straightforward; the '.methods' call is already made within the 'namespace' method

20:58 <henk> I’m trying to "make this better": https://github.com/ruby-rbot/rbot/blob/master/Gemfile.lock I’d appreciate any suggestion on how to do this. in particular what I want to do is "minimize it", i.e. figure out which of these are actually really needed, in which version, which information is redundant, and so on. more particularly: I (and others) feel into the "dependabot trap" and updated

20:58 <henk> requirements without thinking too much about whether this makes sense. I reverted some of that already but there might be more I can "trim" or "relax".

20:59 <henk> I also wonder whether I really need it or the Gemfile (without .lock) would be enough. (I’m a noob when it comes to ruby and its tooling, so any pointers in the right direction or explanations are welcome!)

21:02 <weaksauce> you should be committing the lock file too yes

21:03 <nakilon> when gem is a library you commit .gemspec and optionally Gemfile for development; when gem is a tool you commit Gemfile and Gemfile.lock

21:24 <henk> mhm, ok, thanks! I also thought about it a bit more and I think my judgement of the "dependabot trap" is not quite correct … it’s actually relevant for security. and I don’t like it /-: I want to leave it up to people to make sure they use secure versions _where they assess the risk as such that they need to_. but AFAIU the Gemfile.lock it will force them to use certain versions. at least as

21:24 <henk> long as they install rbot using bundler‽ does the Gemfile.lock have significance with any other tools?