Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Kareem Hepburn
@magicalbanana
group :tools do
  gem 'rubocop'
  gem 'guard'
  gem 'guard-rspec'
  gem 'guard-rubocop'
  gem 'byebug', platform: :mri
end
Piotr Solnica
@solnic
that’s a standard Bundler feature
Kareem Hepburn
@magicalbanana
Oh nice.
So tools would be like development dependency or the development grouping in rails?
Piotr Solnica
@solnic
yeah, we don’t bundle that group on CI
Kareem Hepburn
@magicalbanana
Why not?
Piotr Solnica
@solnic
because we don’t need them to run tests
Kareem Hepburn
@magicalbanana
Ah, gotcha.
So much I need to learn with bundler, so much.
Kareem Hepburn
@magicalbanana
What’s gt? for?
Luca Guidi
@jodosha
@magicalbanana Greater than
Kareem Hepburn
@magicalbanana
Ah, lol.
If I stuck with C# I would prolly guessed that. Ruby and it’s conventions has made my abbreviation skills weak.
Piotr Solnica
@solnic
hah :)
Kareem Hepburn
@magicalbanana
@solnic where I work that gt? would never fly. They emphasize on convention here (the rails one) too much. :(
@solnic so is dry-validations stable?
Piotr Solnica
@solnic
no, it’s 0.4.2 atm
will push 0.5.0 later today or tomorrow
Kareem Hepburn
@magicalbanana
Ah, how long before you think it becomes stable?
Piotr Solnica
@solnic
I’ll release 1.0.0 once I’m done with error message compilation optimizations
it’s my personal pet peeve :joy:
targeting February for 1.0
Kareem Hepburn
@magicalbanana
I get that. I think I’ll start doing benchmarks for all the validators I am aware of. Should be good.
Piotr Solnica
@solnic
dry-data 0.5 and dry-validation 0.5 were released and now they both depend on the new dry-logic gem
@kwando I added "default value” support in this release, I remember you asked about a DSL for that the other day…it’s a bit different than in virtus and currently only supports a simple value, so no procs or method names are supported
Tim Riley
@timriley
An interesting thing I’m seeing with the rodakase apps we have and these container-based gems with finalization (i.e. rom and dry-data now, with its types module) is that if you want 2 distinct places for registering entities with those gems (i.e. in our rodakase app we have “main” and “admin” sub-apps) then it becomes pretty hard to do.
since the finalization needs to somehow span the boot sequence of both of the sub-apps. Or perhaps they ideally have their own containers/namespaces, which isn’t quite possible with those gems, I think.
Piotr Solnica
@solnic
"Entities" being?
Tim Riley
@timriley
ah, so whatever the gem’s concerned with registering: relations, commands, mappers, etc. for rom and then type definitions for dry-d
Tim Riley
@timriley
I think in dry-d’s case it’s not too bad. I’d just configure a top-level Types namespace globally in the app, then use modules underneath that if any of the sub-apps need specific types defined.
The finalizing bit might be tricky still. Let me look at the code.
Andy Holland
@AMHOL
@solnic we spoke about maybe doing something like this rather than the finalize/namespace configuration, don't know if you remember?
module Dry
  module Data
    def self.register_types(mod)
      define_constants(mod, container._container.keys)
    end
  end
end
Tim Riley
@timriley
Making it an explicit thing you can do a number of times?
Andy Holland
@AMHOL
Then you can do:
module Core
  module Types
    Dry::Data.register_types(self)
  end
end
@timriley yeah
Tim Riley
@timriley
I like that approach.
Andy Holland
@AMHOL
Me too :)
Piotr Solnica
@solnic
there’s no need for that, types are objects, assign them to constants and you’re done
the finalization is there so that dry built-in types are defined within your namespace
Tim Riley
@timriley
Ah, right.
Piotr Solnica
@solnic
we can provide default namespace that you can just include it
include Dry::Data::Types::BuiltIn or something
Piotr Solnica
@solnic
@timriley re configuring deps, you're talking about deps that are places in diff subapps but share common booting code?
Tim Riley
@timriley
In this case they share common boot code (relations), yeah. My situation was that I thought I’d need a mapper in a sub-app to map to one of its own entity classes – turns out I don’t, so I’ve avoidede the issue for now.
Piotr Solnica
@solnic
I am working on improving this. Ie it is possible to define rom as a standalone component shared between subapps. So it is not part of the booting process of any app
Tim Riley
@timriley
ah, interesting
Piotr Solnica
@solnic
So anything that requires rom and some of its components, can define it as a dep and it will trigger its booting etc
Tim Riley
@timriley
How would the finalization of rom’s own container work there?