These are chat archives for dry-rb/chat

19th
Jul 2016
Hector Sansores
@hectorsq
Jul 19 2016 01:35
Tim Riley
@timriley
Jul 19 2016 01:39
So shotgun is broken with the new rack (rtomayko/shotgun#61), and I’m not exaclty confident that the maintainer/s will turn around a release any time soon… We recommend it as the code reloading tool for dev with dry-web-roda. I wonder whether we fork it (temporarily or otherwise) or look for something else.
Sinatra’s FAQ recommends https://github.com/alexch/rerun
Tim Riley
@timriley
Jul 19 2016 01:55
Which seems to work pretty well.
Tim Riley
@timriley
Jul 19 2016 06:39
But the file monitoring->reloading is too slow in practice, I found after a morning of usage.
Tim Riley
@timriley
Jul 19 2016 07:08
It doesn’t really work with dry-container
Hannes Nevalainen
@kwando
Jul 19 2016 08:16
I would be sad to not be able to use shotgun in the future =(
Tim Riley
@timriley
Jul 19 2016 08:24
Well, throwing a fork up onto rubygems is easy :)
I just took this as an opportunity to try a couple of other things.
Turns out that shotgun is actually very nice and easy compared to the rest!
Hannes Nevalainen
@kwando
Jul 19 2016 08:28
yeah, shotgun is refreshingly simple to use =)
may not be the fastest but I never had any real issues with it
Tim Riley
@timriley
Jul 19 2016 08:40
Yeah.
Tim Riley
@timriley
Jul 19 2016 08:45
I'm interested in experimenting with a "development mode" for dry-component where it doesn't auto-register up-front and instead lazily loads files as they are required. Might help keep the load time down in dev as apps get larger.
Piotr Solnica
@solnic
Jul 19 2016 09:27
In theory, shredding containers, removing constants and re-loading files should be simpler and more stable
Since a container has access to file names, constants and objects
henricus louwhoff
@hl
Jul 19 2016 09:41
for the lack of a better (faster) option I'm using guard
Piotr Solnica
@solnic
Jul 19 2016 09:43
forking shotgun is probably a quick win though
Tim Riley
@timriley
Jul 19 2016 09:57
"Shredding containers," @solnic? I'm not really sure what that means 😬
Piotr Solnica
@solnic
Jul 19 2016 10:00
@timriley my bad english
I meant removing then and replacing with new ones
Tim Riley
@timriley
Jul 19 2016 10:06
Ah, right. I might open a discussion about this on GH at some point so we have a bit more time/space to share ideas.
Nikita Shilnikov
@flash-gordon
Jul 19 2016 10:08
@solnic how would you track constants loaded by require/require_relative directly, not through a container? It's gonna be tricky. At least without patching require + require_relative
Tim Riley
@timriley
Jul 19 2016 10:09
Yeah. That's what auto_reloader does.
So at least it's transparent.
Piotr Solnica
@solnic
Jul 19 2016 10:12
I would not? :h
timriley @timriley wonders if we're talking about code reloading anymore :3
Piotr Solnica
@solnic
Jul 19 2016 10:14
Container controls file loading and constant handling. You detect after each require what new constants showed up
You can*
Nikita Shilnikov
@flash-gordon
Jul 19 2016 10:14
@solnic hm, accepted
Piotr Solnica
@solnic
Jul 19 2016 10:14
and we don't have to monkey patch Kernel
Tim Riley
@timriley
Jul 19 2016 10:15
so I guess the container is the entry point, and when container files get loaded, their own "require" lines for non-container items means that a container-based system can even detect when they are loaded, yes?
You'd still need to special case things like your web routes, etc., though?
Piotr Solnica
@solnic
Jul 19 2016 10:32
yes, this will need more APIs
Piotr Solnica
@solnic
Jul 19 2016 10:41
if you can reliably detect what constants showed up after requiring a file then 80% of the job is done
oh and just to be clear, I’m talking about the enhanced container API in dry-component
our dry-container is pretty much a thread-safe storage for things :)
Tim Riley
@timriley
Jul 19 2016 10:57
Yes :)
Ralf Schmitz Bongiolo
@mrbongiolo
Jul 19 2016 14:22
@solnic quick question: will you deprecate the usage of Dry::Validation::Schema.configure { |config| ... }? Since the latest docs are using the MyAppSchema < Dry::Validation::Schema and then initializing them with Dry::Validation.Schema(MyAppSchema) { ... }. It's all working for now, just wanted to know if there's a real difference between them or any advantage on using one or another.
Piotr Solnica
@solnic
Jul 19 2016 14:27
@mrbongiolo no it’s not going away. There’s a difference between the two that I’d like to remove though, because essentially both do the same - configure a schema class
Ralf Schmitz Bongiolo
@mrbongiolo
Jul 19 2016 14:27
The nice thing about the Schema.configure is that it changes the default schema, so I don't have to initialize each new Schema with my BaseSchema...
but I guess it doesn't allow defining rules or predicates, like define! on the BaseSchema?
Andy Holland
@AMHOL
Jul 19 2016 15:04
@solnic been thinking about it and it's probably better to remove
Global configuration and all
Unless we have some way of creating an isolated validation schema for library authors
Piotr Solnica
@solnic
Jul 19 2016 15:22
configuration is per-schema class
so it’s OK
there’s a huge configuration portion that’s static and at class-level
and then validation schema objects are used at run-time
so removing that would be kind of awkward
esp that it’s safe wrt run-time, because even if something changes the global config it won’t affect already initialized schemas
even when you do Schema#with at run-time
and if it DOES then it’s a bug
Ralf Schmitz Bongiolo
@mrbongiolo
Jul 19 2016 15:37
@fran-worley shouldn't included_in? work with ranges?
Andy Holland
@AMHOL
Jul 19 2016 15:50
Cool
Ralf Schmitz Bongiolo
@mrbongiolo
Jul 19 2016 15:59
@solnic I just upgraded dry-v to 0.9.1 and the Schema broke with: I18n::InvalidLocale: :en is not a valid locale, this is a rails env, with default locales set like this:
I18n.config.enforce_available_locales = true
    config.i18n.available_locales = ["pt-BR"]
    config.i18n.default_locale = "pt-BR"
it was working on 0.8.0
Piotr Solnica
@solnic
Jul 19 2016 16:02
@mrbongiolo upgrade to 0.9.2
there was an issue with I18n being configured/loaded too early
maybe that’s it
Ralf Schmitz Bongiolo
@mrbongiolo
Jul 19 2016 16:03
ok, I just upgraded, not sure why it didn't get .2 from ruby gems
@solnic the same issue on 0.9.2
Piotr Solnica
@solnic
Jul 19 2016 16:11
welllll it might be because you override available locales, not sure why it worked before, probably loading-order issue
you gotta append your locales, not override
I gotta check if dry-v doesn’t do the same though haha
Ralf Schmitz Bongiolo
@mrbongiolo
Jul 19 2016 16:16
I guess I found it
kind of
It seems like I have to set the :locale option
for some reason it's not using the I18n.default_locale, but the default locale you set on https://github.com/dry-rb/dry-validation/blob/614cc7fb97873b4f3cc8c299e9d6e639ffbf5075/lib/dry/validation/message_compiler.rb#L14
Piotr Solnica
@solnic
Jul 19 2016 16:20
I18n, global mutable state, welcome to :fire:
Ralf Schmitz Bongiolo
@mrbongiolo
Jul 19 2016 16:21
hahaha
Ok, I fixed it by calling result.messages(locale: 'pt-BR')
I guess it would be better to have a config.locale = :en on the Schema configure block, so when I set the messages to i18n I can also set the default locale that I expect
Piotr Solnica
@solnic
Jul 19 2016 16:27
@mrbongiolo pls report an issue describing problems you’ve had
Ralf Schmitz Bongiolo
@mrbongiolo
Jul 19 2016 16:27
Ok
Fran Worley
@fran-worley
Jul 19 2016 16:39
@mrbongiolo should do. It should just work with anything that responds to includes?
Rafael George
@cored
Jul 19 2016 16:40
found like this is to the same concept of the talk that you presented at full stack fest @solnic http://gamesfromwithin.com/data-oriented-design
Ralf Schmitz Bongiolo
@mrbongiolo
Jul 19 2016 16:40
@fran-worley in the latest version it "kinds" of work, but the error compilers fails with: dry-rb/dry-validation#217
instead of sending the list argument, it uses list_left and list_right
Piotr Solnica
@solnic
Jul 19 2016 16:44
right, that’s our breaking change (it’s in changelog)
Fran Worley
@fran-worley
Jul 19 2016 16:44
We convert message tokens automatically based on the type of value. A range is converted to _left and _right and an array is converted to a comma separated string. The idea is to make a 'pretty' string. Is this not what you want?
Ralf Schmitz Bongiolo
@mrbongiolo
Jul 19 2016 16:45
But the key won't work for arrays and ranges then.
Fran Worley
@fran-worley
Jul 19 2016 16:46
We need message types again like with size don't we...
Ralf Schmitz Bongiolo
@mrbongiolo
Jul 19 2016 16:46
When an array is used, then the messages receives a list, when a range is used then it receives list_left and list_right, but the key to lookup is always the same: errors.included_in?
I guess so
changing my yml to this:
    included_in?:
      arg:
        default: "tamanho tem que ser %{list}"
        range: "tamanho tem que estar entre: %{list_left} - %{list_right}"
Fran Worley
@fran-worley
Jul 19 2016 16:49
Any luck?
Ralf Schmitz Bongiolo
@mrbongiolo
Jul 19 2016 16:50
yep, it worked
I'll update the default errors.yml and send a PR
Fran Worley
@fran-worley
Jul 19 2016 16:50
Thanks can up change excluded_from aswell?
Ralf Schmitz Bongiolo
@mrbongiolo
Jul 19 2016 16:51
ok
shouldn't we get rid of exclusion? and inclusion? keys already?
Fran Worley
@fran-worley
Jul 19 2016 17:05
They have to stay as the predicates are just deprecated
I probably wouldn't bother updating them as people should just migrate to the new predicate names.
Ralf Schmitz Bongiolo
@mrbongiolo
Jul 19 2016 17:09
Ok, no problem
Ralf Schmitz Bongiolo
@mrbongiolo
Jul 19 2016 17:43
@solnic dynamic arguments doesn't work with rules?
Piotr Solnica
@solnic
Jul 19 2016 17:54
@mrbongiolo you mean rule API?
Ralf Schmitz Bongiolo
@mrbongiolo
Jul 19 2016 17:54
Yes @solnic
I was trying to use something like: rule() { year.gteq?(current_year) and having that current_year defined in the configure block, but it said that the it couldn't find the predicate
Piotr Solnica
@solnic
Jul 19 2016 17:56
yes it’s not supported yet
Ralf Schmitz Bongiolo
@mrbongiolo
Jul 19 2016 17:58
Ah ok