These are chat archives for dry-rb/chat

11th
May 2016
Joe Van Dyk
@joevandyk
May 11 2016 03:09
@timriley you should finish docs/examples for that dry web template project
Tim Riley
@timriley
May 11 2016 03:24
@joevandyk Yep, the goal is to have a lot of this stuff in place by June 23:
I’m hoping that some of this stuff can actually go up into dry-web docs, rather than live inside our skeleton.
Luca Guidi
@jodosha
May 11 2016 07:16
@AMHOL Thanks :smile: !
@fran-worley That's awesome! Yes, mark with a xand report as a GH issue.
Trung Lê
@joneslee85
May 11 2016 08:08
@timriley hey Tim, how's thing going? Just have a quick question, in the page http://dry-rb.org/gems/dry-types/optional-values/, it seems to me the code is not correct:
maybe_string = Types::Strict::String.optional

maybe_string[nil]
# => None

maybe_string[nil].fmap(&:upcase)
# => None
I could not get fmap running without errors
let me explain abit, the maybe_string[nil] actually returns nil
Trung Lê
@joneslee85
May 11 2016 08:17
I think I know why
I think I am not yet on the master upstream branch
Tim Cooper
@coop
May 11 2016 08:26

Hi @timriley @solnic (I realise he’s out for May) - sorry I didn’t get back to you guys earlier I’ve been a bit busy with work. I’ve replied to my mentions below:

btw we shouldn't allow value w/o args I think, it does nothing
this should raise an arg error I believe

@solnic I believe I raise an exception already if this happens. I will double check.

re you planning to extract attr DSL to a separate gem? I just realized this is gonna block 0.8.0 release

@solnic I wasn’t planning on extracting attr DSL into a separate gem, I have zero interest in it so I’m not the right person anyway. If people want attr support I think it would be fine to pin them to version 0.7.x. If they want it the feature they can write the gem.

Does anyone know how to create a validator from a Dry::Types::Struct

@timriley @kwando I built schemas from types, not sure about structs (I believe I did) - let me find the code and I will link to it.

Alexander Gräfe
@rickenharp
May 11 2016 08:46
Hi. This might be a stupid question, but I want to try out dry-container in a Rails/Trailblazer app. Has anybody else done this, and if yes, where did you put the container setup? In an initializer?
Fran Worley
@fran-worley
May 11 2016 10:02

@jodosha what is this trying to test? https://github.com/dry-rb/dry-validation/blob/master/spec/integration/form/predicates/array_spec.rb#L74-L128

It is in the array_spec so I assume we are testing cases when an input is an array. These specs are actually testing if a string (the input) is included_in? an array (option for the predicate). I think what you are looking for is the includes? predicate which instead looks for a value in the input.

If I'm correct, I have a PR to update that portion of the spec. Otherwise could we take it out as tests for included_in are in a separate spec file.

Luca Guidi
@jodosha
May 11 2016 10:12
@fran-worley I'm confused ( :smile: ), as I assumed that inclusion? was replaced by included_in? and exclusion? by excluded_from?. Is that correct?
Fran Worley
@fran-worley
May 11 2016 10:14
Yes but those predicates work by testing that an input is included in a given value e.g. input.included_in?([1,2,3]) where input is a single value.
Luca Guidi
@jodosha
May 11 2016 10:15
@fran-worley But we can't trust to receive a single value like 1, that's the purpose of that tests. :)
(lunch, brb - sorry)
Fran Worley
@fran-worley
May 11 2016 10:17
@jodosha I'm not disputing that but I am questioning why we are testing it in array_spec. I assumed array_spec was to cover cases where an input was an array. Those two predicates are not designed for array input and are tested in separate files.
You could test includes? and excludes? here as they are relevant to arrays
Luca Guidi
@jodosha
May 11 2016 10:42

@fran-worley Ohhhhh I'm sorry about the mistake, the :coffee: helped to see the problem. My apologize :smile:. Yes, you're right, that specs are misplaced.

The line https://github.com/dry-rb/dry-validation/blob/master/spec/integration/form/predicates/array_spec.rb#L77 should use optional, in order to mirror https://github.com/dry-rb/dry-validation/blob/master/spec/integration/form/predicates/array_spec.rb#L5, which uses required.

# L77
optional(:foo) { array? { each { int? } } }
Fran Worley
@fran-worley
May 11 2016 10:43
I thought it looked a bit odd... We've also got an _test file instead of spec. I'll raise a PR to fix the two
Luca Guidi
@jodosha
May 11 2016 10:44
@fran-worley Again, my apologize :( - I edited that files over and over on hanami-v and then ported to dry-v.
@fran-worley Thanks for spotting these mistakes :)
Fran Worley
@fran-worley
May 11 2016 10:45
Don't apologise, what you have done is amazing I'm just adding too it and found a couple of things!
Luca Guidi
@jodosha
May 11 2016 10:48
:)
Fran Worley
@fran-worley
May 11 2016 10:51
@jodosha dry-rb/dry-validation#153
Michał Pietrus
@blelump
May 11 2016 10:52
@rickenharp , yep, it's enough
Alexander Gräfe
@rickenharp
May 11 2016 10:52
@blelump Cool, thanks!
Fran Worley
@fran-worley
May 11 2016 10:56
No as due to the update to drytypes (pr 88) empty strings are coerced to an empty array
The logic being that an html form will either pass an array with values or nil so to get around it you can force an empty string to be returned.
Tim Riley
@timriley
May 11 2016 10:59
Yeah. This was from me today. The issue is that with an HTML form post, you can pass a populated array, or no array at all. There’s no way to pass a blank array. So we can do this by just sending the value as e.g. a hidden input with no value, which comes through as a blank string, which we can now coerce to an empty array if the dry-v form schema types that key to an array.
Thanks for helping with the resulting fixes, @fran-worley :)
Luca Guidi
@jodosha
May 11 2016 11:00
@fran-worley @timriley But we can receive a blank value (via form hijacking) and this should fail too: https://github.com/dry-rb/dry-validation/blob/00fdfd1b5478ace4a877359d8c8fec28b772bfd9/spec/integration/form/predicates/array_spec.rb#L37
Tim Riley
@timriley
May 11 2016 11:01
That shouldn’t fail, because "" just becomes an empty array
which satisfies required(:foo) { array? { each { int? } } }
that’s not saying the array has to have any minimum length
@joneslee85 did you work everything out?
Luca Guidi
@jodosha
May 11 2016 11:03
@timriley Don't look at our internal data transformations, but how a developer expects things to work. So I (a developer building my form), expect that foo is an array of integers, otherwise the software should reject the request. Now the question is: does an empty string satisfy my model domain rule? IMO it doesn't, so it should reject the request.
@timriley first of all, an empty string isn't an array so it should fail while checking the type.
Tim Riley
@timriley
May 11 2016 11:05
@jodosha This is actually a feature I approached as a developer. We make a form builder. Our form builder allows repeating nested data (e.g. similar to “accepts_nested_attributes” from Rails). And our form builder needs to be able to submit when that array of nested things is empty.
Otherwise, the key just doesn’t get submitted at all. So the server can’t know if the user explicitly cleared out the array of nested items or not.
This is a problem with HTML forms, and we need to handle it in some way.
Fran Worley
@fran-worley
May 11 2016 11:06
@jodosha This change is only implemented when using Form as @timriley explains. When using Schema your expectations are correct and '' is not coerced to []
Tim Riley
@timriley
May 11 2016 11:06
I think it’s a pretty clear feature of dry-v Form schemas that type coercion happens when you specify types.
And this is the best coercion possible to support forms being able to submit empty arrays or hashes.
Does that make it a bit clearer why we did this?
Luca Guidi
@jodosha
May 11 2016 11:11

Does that make it a bit clearer why we did this?

Yes it's clear. Thanks.

Tim Riley
@timriley
May 11 2016 11:12
@jodosha Cool :)
Luca Guidi
@jodosha
May 11 2016 11:12
:)
Fran Worley
@fran-worley
May 11 2016 11:12
Shall I merge then?
Luca Guidi
@jodosha
May 11 2016 11:14
:shipit:
Fran Worley
@fran-worley
May 11 2016 11:16
Any ideas why the build failed?
Jeff Dickey
@jdickey
May 11 2016 11:19
Hey, guys; trying to use dry-validation from a Gem, "borrowing" the not_eql? predicate that's not in a released Gem yet. Hilarity ensues, now apparently localised to being able to build and use the error message. Gist of the carnage. Any pointers?
Luca Guidi
@jodosha
May 11 2016 11:19
@fran-worley nope. the odd thing is that only one of the two builds failed. :(
Fran Worley
@fran-worley
May 11 2016 11:20
@jodosha I know and I can't replicate those fails locally...
Jeff Dickey
@jdickey
May 11 2016 11:20
I know I'm using the wrong key name for the error message at %{eql_value}, but everything else I've tried just gives a blank
Fran Worley
@fran-worley
May 11 2016 11:20
@jdickey have you tried value?
@jdickey the error message options_for for :not_eql? is not in master yet
you need the PR I'm writting now from this branch: https://github.com/dry-rb/dry-validation/tree/updates_for_new_predicates
Tim Riley
@timriley
May 11 2016 11:22
@jdickey in the absence of a specific options_for_not_eql in the error messages compiler, it looks like it gives you name, rule and value keys - do any of those work for you?
Fran Worley
@fran-worley
May 11 2016 11:23
@timriley you won't be able to get the value you wanted the input to equal without the options_for
Jeff Dickey
@jdickey
May 11 2016 11:23
yes, and it schema_errors comes back as
{
    :proposed_by => [
        [0] "must not be equal to Guest User",
        [1] "must not be equal to "
    ]
}
that's when the error message includes %{value}
Fran Worley
@fran-worley
May 11 2016 11:24

@jdickey I've looked and you need to either use this branch
https://github.com/dry-rb/dry-validation/tree/updates_for_new_predicates

and value as your message option. Or wait for my PR as this predicate is not fully supported in master yet

(I'd advise the second option as the PR is coming today and the branch is not finished)
Jeff Dickey
@jdickey
May 11 2016 11:25
@fran-worley Thanks; will wait. I've already killed a day banging my head against this; a few more hours won't inflict significantly more pain. Thanks!
Fran Worley
@fran-worley
May 11 2016 11:25
@jodosha Can I get it to retry the build?
Tim Riley
@timriley
May 11 2016 11:26
@jdickey btw, thanks for your last considerate comment on reddit :)
Jeff Dickey
@jdickey
May 11 2016 11:27
@timriley welcome. I really need to stop going off half-cocked so often. I've only been telling myself that for 35 years :P
Tim Riley
@timriley
May 11 2016 11:27
hehe
Jeff Dickey
@jdickey
May 11 2016 11:27
that was a great explanation, by the way
Tim Riley
@timriley
May 11 2016 11:28
It’s actually helpful to be challenged on things like this. I want to get better at conveying the worthiness of these gems.
Luca Guidi
@jodosha
May 11 2016 11:29
@fran-worley please do :)
Jeff Dickey
@jdickey
May 11 2016 11:29
I really do think it's split off into a two-layer cake; the 'lower-level" tools came first, and now that you're building on that foundation, there's a bit of mental gymnastics that's required of the reader/would-be user that isn't clearly beneficial until after the second or third reading has had a chance to sink in somewhat
and, as I said, I'm not at all sure that you can do anything much about that beyond present it as a low-level/high-level dichotomy
Tim Riley
@timriley
May 11 2016 11:30
Yeah, it’s an interesting way to see it.
Alexander Gräfe
@rickenharp
May 11 2016 11:36
Do I understand that whole dry-container correctly, insofar that I could swap a connector to an external service easily when running tests, so that a dummy connector is used instead?
Tim Riley
@timriley
May 11 2016 11:36
@rickenharp yep, you can do that.
@rickenharp https://github.com/dry-rb/dry-container/pull/11#issuecomment-184765175 may be instructive - this is released now
Fran Worley
@fran-worley
May 11 2016 11:38
@jodosha I know what it is... That file used to be called _test and so wouldn't have been run before.
Alexander Gräfe
@rickenharp
May 11 2016 11:38
@timriley That answers the question I was about to type, thanks! :D
Tim Riley
@timriley
May 11 2016 11:38
@rickenharp haha, great!
Luca Guidi
@jodosha
May 11 2016 11:39
@fran-worley but still, it passes for one build and not for the other one :/
Fran Worley
@fran-worley
May 11 2016 11:39
@jodosha yeah, and I can't replicate it locally.
Can we merge anyway?
Luca Guidi
@jodosha
May 11 2016 11:40
@fran-worley That can lead to intermittent errors on master. Did you tried to restart that build?
Fran Worley
@fran-worley
May 11 2016 11:40
Yeah failed again for the same 2 specs
Alexander Gräfe
@rickenharp
May 11 2016 11:40
I'll be honest, I'm still not quite seeing the benefit of all of this, but I am 99% sure that is me not understanding the whole dry-rb ecosystem completely (and Rails-induced architecture blindness...)
Fran Worley
@fran-worley
May 11 2016 11:41
@jodosha
  1) Predicates: Lt as macro with required with value with missing input is not successful

     Failure/Error: expect(result).to be_failing ['is missing', 'must be less than 23']

       expected that #<Dry::Validation::Result output={} messages={:foo=>["is missing"]}> would be failing (["is missing", "must be less than 23"])

     # ./spec/integration/schema/predicates/lt_spec.rb:151:in `(root)'

  2) Predicates: Lt with required with missing input is not successful

     Failure/Error: expect(result).to be_failing ['is missing', 'must be less than 23']

       expected that #<Dry::Validation::Result output={} messages={:foo=>["is missing"]}> would be failing (["is missing", "must be less than 23"])

     # ./spec/integration/schema/predicates/lt_spec.rb:21:in `(root)'

Finished in 14.3 seconds (files took 3.36 seconds to load)

1731 examples, 2 failures, 39 pending
It only seems to fail on jruby-9000
Luca Guidi
@jodosha
May 11 2016 11:42
@fran-worley Did you used the same build RSpec seed on local machine?
Fran Worley
@fran-worley
May 11 2016 11:50
@jodosha Have now, still no problem I can only assume that it is something to do with jruby...
Luca Guidi
@jodosha
May 11 2016 11:56
@fran-worley I'd say to mark these two as pending examples and add a comment. So we can merge the PR without affecting build stability.
Changing topic: how do you folks suggest to implement validation rule for acceptance? I have a signup form with a classical "accept terms of service" check box. How is done currently, and.. do we want to implement a macro/predicate for it? Eg. required(:terms).accepted. Thoughts? :smile:
Tim Riley
@timriley
May 11 2016 12:03
Here’s how I would do it manually
Fran Worley
@fran-worley
May 11 2016 12:03
@jodosha I think that as we support confirmation we should also support accepted.
Tim Riley
@timriley
May 11 2016 12:03
form = Dry::Validation.Form do
  required(:accept_legal).value(:bool?, eql?: true)
end

form.("accept_legal" => "1")
# => #<Dry::Validation::Result output={:accept_legal=>true} messages={}>
form.("accept_legal" => "0")
# => #<Dry::Validation::Result output={:accept_legal=>false} messages={:accept_legal=>["must be equal to true"]}>
But I agree, this is a common enough thing that a nice macro may help.
Fran Worley
@fran-worley
May 11 2016 12:04
@timriley you know that there is a true? predicate?
Tim Riley
@timriley
May 11 2016 12:04
oh, haha
even better
Luca Guidi
@jodosha
May 11 2016 12:05
That means it would boil down to: required(:accept_legal).value(:true?)?
Tim Riley
@timriley
May 11 2016 12:06
I think you’d need to type it to :bool? if you want check-box values to be coerced to a real bool?
so .value(:bool?, :true?)
Fran Worley
@fran-worley
May 11 2016 12:06
@timriley could we handle that automatically in Form?
Luca Guidi
@jodosha
May 11 2016 12:06
I see :) Does a macro makes sense? required(:accept_legal).accepted?
Tim Riley
@timriley
May 11 2016 12:07
Yeah, I think that would be nice. It could also have a more appropriate error message.
@fran-worley I think the way we handle it right now is best for flexibility - a macro seems more reasonable for this common case?
Fran Worley
@fran-worley
May 11 2016 12:08
yes makes sense
Fran Worley
@fran-worley
May 11 2016 12:45

@jodosha I'd be interested to hear your thoughts on this:

dry-rb/dry-logic#10

Fran Worley
@fran-worley
May 11 2016 14:10
What do you think? This should fix @jdickey issues with not_eql and adds to the spec coverage
dry-rb/dry-validation#155
Does anyone with travis experience know how to get this passing?
https://travis-ci.org/dry-rb/dry-logic/jobs/129433825
Luca Guidi
@jodosha
May 11 2016 14:14
@fran-worley That is a Travis CI problem, can you restart failing jobs?
Fran Worley
@fran-worley
May 11 2016 14:16
@jodosha tried it twice. Its because the listen gem is looking for Ruby 2.2.3 and up travis builds include 2.0 and 2.1
Fran Worley
@fran-worley
May 11 2016 14:25
Its not my Travis CI day!!
Luca Guidi
@jodosha
May 11 2016 14:26
@fran-worley I guess you can tweak this line here: https://github.com/dry-rb/dry-logic/blob/master/.travis.yml#L4
@fran-worley and make it --without tools, it should ignore this group https://github.com/dry-rb/dry-logic/blob/master/Gemfile#L9
Fran Worley
@fran-worley
May 11 2016 14:26
I can't understand why dry-v isn't blowing up though??
the only difference between the two is that dry-v excludes benchmarks
Luca Guidi
@jodosha
May 11 2016 14:27
Too late in the day to understand why ;)
Fran Worley
@fran-worley
May 11 2016 14:30
If I can fix the Dry-Logic build should I merge?
Jeff Dickey
@jdickey
May 11 2016 14:33
and release a new Gem pretty please? :)
Fran Worley
@fran-worley
May 11 2016 14:34
@jdickey I think releases have to go through @solnic
Jeff Dickey
@jdickey
May 11 2016 14:35
ok, so that's still going to leave me out in the code. Apps can link against master just fine; Gem dependency management would have to improve spectacularly to reach "primitive" :mask:
and that's not something we're going to fix in our various local "tonights" :P
thanks for the help anyway, though; it's been illuminating, and I've a craptastic workaround that'll last me until we do get a release
Fran Worley
@fran-worley
May 11 2016 14:37
@jdickey if I can get these builds to pass then I can get the whole lot into master. That should at least enable you to check that it works for you.
Jeff Dickey
@jdickey
May 11 2016 14:39
@fran-worley not unless someone can explain how I can link against a Github repo in a Gemspec, which I've always understood to be unsupported. Thanks, though
I can do a demo app that proves that it works, but that's not going to move my boss's ball forward
Fran Worley
@fran-worley
May 11 2016 14:40
@jdickey can't you just add it into the gemfile like we have in dry-validation? https://github.com/dry-rb/dry-validation/blob/master/Gemfile#L3-L5
@jdickey as a temporary measure obviously
Jeff Dickey
@jdickey
May 11 2016 14:41
$h!t, you're right; these 18-hour days have pumpkinised my brain. I'm good :sweat_smile:
Fran Worley
@fran-worley
May 11 2016 14:42
@jdickey obviously won't work until I've merged it but you could even point to the branch for now as its passing
Jeff Dickey
@jdickey
May 11 2016 14:43
@fran-worley ayup; again, profuse thanks
jdickey @jdickey scrapes henhouse worth of egg off face, wipes spectacles, and starts feeling better about the day :)
Fran Worley
@fran-worley
May 11 2016 14:53
Woop woop dry-rb/dry-logic#11 . @timriley @jodosha can I merge?
Jeff Dickey
@jdickey
May 11 2016 15:49

Hey, guys; no joy on adding dry-validation from the updates_for_new_predicates branch. I've added to my Gemfile

gem 'dry-logic', require: false, github: 'dry-rb/dry-logic'
gem 'dry-validation', require: false, github: 'dry-rb/dry-validation', branch: "updates_for_new_predicates"

and in my code, I have this bit of code

        schema = Dry::Validation.Schema do
          key(:proposed_by).required(not_eql?: 'Guest User')
        end
        schema_errors = schema.(@attributes.to_h).messages

and :boom:

Error:
Prolog::UseCases::ProposeEditContribution::has a #call method that#test_0001_accepts a :justification parameter string:
ArgumentError: +not_eql?+ is not a valid predicate name
    /usr/local/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/dry-validation-0.7.4/lib/dry/validation/schema.rb:195:in `[]'
    /usr/local/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/dry-logic-0.2.2/lib/dry/logic/rule_compiler.rb:54:in `visit_predicate'
    /usr/local/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/dry-logic-0.2.2/lib/dry/logic/rule_compiler.rb:18:in `visit'
    /usr/local/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/dry-logic-0.2.2/lib/dry/logic/rule_compiler.rb:32:in `visit_key'
    /usr/local/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/dry-logic-0.2.2/lib/dry/logic/rule_compiler.rb:18:in `visit'
    /usr/local/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/dry-logic-0.2.2/lib/dry/logic/rule_compiler.rb:59:in `visit_and'
    /usr/local/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/dry-logic-0.2.2/lib/dry/logic/rule_compiler.rb:18:in `visit'
    /usr/local/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/dry-logic-0.2.2/lib/dry/logic/rule_compiler.rb:59:in `visit_and'
    /usr/local/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/dry-logic-0.2.2/lib/dry/logic/rule_compiler.rb:18:in `visit'
    /usr/local/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/dry-validation-0.7.4/lib/dry/validation/schema.rb:254:in `block in initialize_rules'
    /usr/local/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/dry-validation-0.7.4/lib/dry/validation/schema.rb:253:in `each'
    /usr/local/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/dry-validation-0.7.4/lib/dry/validation/schema.rb:253:in `each_with_object'
    /usr/local/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/dry-validation-0.7.4/lib/dry/validation/schema.rb:253:in `initialize_rules'
    /usr/local/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/dry-validation-0.7.4/lib/dry/validation/schema.rb:174:in `initialize'
    /usr/local/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/dry-validation-0.7.4/lib/dry/validation/schema.rb:46:in `new'
    /usr/local/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/dry-validation-0.7.4/lib/dry/validation/schema.rb:46:in `new'
    /usr/local/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/dry-validation-0.7.4/lib/dry/validation.rb:37:in `Schema'
    /Users/jeffdickey/src/rails/meldd/prolog-use_cases/lib/prolog/use_cases/propose_edit_contribution.rb:82:in `form_object_valid?'
    /Users/jeffdickey/src/rails/meldd/prolog-use_cases/lib/prolog/use_cases/propose_edit_contribution.rb:75:in `run_steps'
    /Users/jeffdickey/src/rails/meldd/prolog-use_cases/lib/prolog/use_cases/propose_edit_contribution.rb:43:in `call'
    test/prolog/use_cases/propose_edit_contribution_test.rb:214:in `block (3 levels) in <main>'
Fran Worley
@fran-worley
May 11 2016 15:50
@jdickey can you check what version of dry-logic is in your gemfile.lock ?
not_eql? is not included in dry-logic 0.2.2 which is the version it looks like you've got installed locally
Jeff Dickey
@jdickey
May 11 2016 15:52

@fran-worley

$ grep dry-logic Gemfile.lock
  remote: git://github.com/dry-rb/dry-logic.git
    dry-logic (0.2.2)
      dry-logic (~> 0.2, >= 0.2.2)
      dry-logic (~> 0.2, >= 0.2.0)
  dry-logic!
$

yeah; thought it would pick up the master build from that bit added to the Gemfile ?

$ bundle show dry-validation
/usr/local/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/bundler/gems/dry-validation-827176366e0b
$ bundle show dry-logic
/usr/local/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/bundler/gems/dry-logic-a0cb3c4f95d9
$
Fran Worley
@fran-worley
May 11 2016 15:55
@jdickey second one looks fine but your errors are coming from version 0.2.2
/usr/local/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/dry-logic-0.2.2/lib/dry/logic/rule_compiler.rb:54:in `visit_predicate'
Jeff Dickey
@jdickey
May 11 2016 15:57
right; I see
Fran Worley
@fran-worley
May 11 2016 15:57
@jdickey you shouldn't have to declare the dry-logic dependency yourself as it comes through from dry-validation. Have you tried taking that line out and then running bundle again
Jeff Dickey
@jdickey
May 11 2016 15:59
will try that; wait one
Jeff Dickey
@jdickey
May 11 2016 16:05
cute; now I'm getting some delegation errors from forwardable; huh?
Fran Worley
@fran-worley
May 11 2016 16:09
No idea... gist?
Jeff Dickey
@jdickey
May 11 2016 16:10
yeah; wilco
Jeff Dickey
@jdickey
May 11 2016 16:28
@fran-worley sorry that took so long; had a bit of a quandary figuring out what/how completely to include stuff. https://gist.github.com/jdickey/1f19b89019f518f8270c88e7f5982693
Fran Worley
@fran-worley
May 11 2016 16:32
@jdickey is dry-validation included in any other repo from your gemspec or your prolog-core ?
Jeff Dickey
@jdickey
May 11 2016 16:34
negative; just triple-checked. prolog_core predates our exposure to dry-rb, and the current crapfire is the first tentative belly-flop into dry-validations at all
Fran Worley
@fran-worley
May 11 2016 16:41
@jdickey I always hate dependency mess ups. You've cleaned and rebundled I assume. might be worth trying without the require in the dry-validation line on your gemfile and/or removing it from your gemspec temporarily just in case.
Jeff Dickey
@jdickey
May 11 2016 16:43
@fran-worley ISTR the problem is with ActiveModel, which "transitioning" to dry will let us get rid of. Yeah, dependencies are the productivity-killers. I've got one other thing to try, and then your bit, and if I'm still beating my head against concrete in an hour's time, I'll fall back and use a different predicate/weird-in-context error message just to get past this. Thanks for your help; I really do appreciate it.
Fran Worley
@fran-worley
May 11 2016 16:44
@jdickey were you encountering your error with Forwardable before you tried to use :not_eql? I can't see how that could be causing the problem as it isn't getting that far
Jeff Dickey
@jdickey
May 11 2016 16:46
@fran-worley No, I wasn't, and that's the mind-shredding part of it. I've seen that problem before, in Rails apps. We've been using delegation in this Gem all ovber the place, and never before just now had a problem with it. Include the dodgy dry-validation, though, and ka-boom!
I didn't realise that the illudium Q-36 explosive space modulator had crept into our dependency tree :P
Fran Worley
@fran-worley
May 11 2016 16:51
@jdickey have you upgraded ruby versions as part of your dry-v experiment. I've not delegators much but I can't see the syntax you've used anywhere... http://ruby-doc.org/stdlib-2.3.0/libdoc/forwardable/rdoc/Forwardable.html

It looks like it should be something like this:

delegate [:article_repo, :authoriser, :contribution_repo, :ui_gateway,  :user_name] =>  :@collaborators

or

def_delegate :@collaborators, :article_repo, :authoriser, :contribution_repo, :ui_gateway,  :user_name
Jeff Dickey
@jdickey
May 11 2016 16:53
I'd used that delegator syntax up until now and it had Just Worked, which I now-as-I-type-this think may well have been an ActiveModel "enhancement" of the syntax. Reworking now as per the official doc and will see how that goes. Who needs sleep? :P
Fran Worley
@fran-worley
May 11 2016 16:55
@jdickey Goodluck!
Jeff Dickey
@jdickey
May 11 2016 16:55
thanks again for your help!
Fran Worley
@fran-worley
May 11 2016 16:56
You're welcome. Give us a shout if you get stuck.
Jeff Dickey
@jdickey
May 11 2016 16:57
will do!
Jeff Dickey
@jdickey
May 11 2016 16:59
Oh, lovely; even more syntax. TAMTOWTDI indeed. Many thanks again
Fran Worley
@fran-worley
May 11 2016 17:00
@jdickey but you can't blame dry-validation for that one :wink2:
Jeff Dickey
@jdickey
May 11 2016 17:03

I wasn't even thinking about that. The last month or so has given me greater motivation to do something rash, like learn Elixir.

Jeff had a problem.
Then he rewrote much of his Ruby code in Elixir.
Now, Jeff had Maybe(2) problems…or Maybe(many_more) :P

Well, that didn't take long :bomb:

I killed the ActiveModel delegator code, with declarations changed accordingly, and I'm back to

$ bundle exec ruby test/prolog/use_cases/propose_edit_contribution_test.rb

# Running tests with run options --seed 42667:

key is deprecated - use required instead.
required is deprecated - use filled instead.
E
Error:
Prolog::UseCases::ProposeEditContribution::has a #call method that#test_0001_accepts a :justification parameter string:
ArgumentError: +not_eql?+ is not a valid predicate name
    /usr/local/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/bundler/gems/dry-validation-827176366e0b/lib/dry/validation/schema.rb:197:in `[]'
    /usr/local/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/dry-logic-0.2.2/lib/dry/logic/rule_compiler.rb:54:in `visit_predicate'
    /usr/local/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/dry-logic-0.2.2/lib/dry/logic/rule_compiler.rb:18:in `visit'
    /usr/local/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/dry-logic-0.2.2/lib/dry/logic/rule_compiler.rb:32:in `visit_key'
    /usr/local/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/dry-logic-0.2.2/lib/dry/logic/rule_compiler.rb:18:in `visit'
    /usr/local/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/dry-logic-0.2.2/lib/dry/logic/rule_compiler.rb:59:in `visit_and'
    /usr/local/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/dry-logic-0.2.2/lib/dry/logic/rule_compiler.rb:18:in `visit'
    /usr/local/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/dry-logic-0.2.2/lib/dry/logic/rule_compiler.rb:59:in `visit_and'
    /usr/local/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/dry-logic-0.2.2/lib/dry/logic/rule_compiler.rb:18:in `visit'
    /usr/local/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/bundler/gems/dry-validation-827176366e0b/lib/dry/validation/schema.rb:256:in `block in initialize_rules'
    /usr/local/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/bundler/gems/dry-validation-827176366e0b/lib/dry/validation/schema.rb:255:in `each'
    /usr/local/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/bundler/gems/dry-validation-827176366e0b/lib/dry/validation/schema.rb:255:in `each_with_object'
    /usr/local/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/bundler/gems/dry-validation-827176366e0b/lib/dry/validation/schema.rb:255:in `initialize_rules'
    /usr/local/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/bundler/gems/dry-validation-827176366e0b/lib/dry/validation/schema.rb:176:in `initialize'
    /usr/local/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/bundler/gems/dry-validation-827176366e0b/lib/dry/validation/schema.rb:46:in `new'
    /usr/local/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/bundler/gems/dry-validation-827176366e0b/lib/dry/validation/schema.rb:46:in `new'
    /usr/local/rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/bundler/gems/dry-validation-827176366e0b/lib/dry/validation.rb:37:in `Schema'
    /Users/jeffdickey/src/rails/meldd/prolog-use_cases/lib/prolog/use_cases/propose_edit_contribution.rb:85:in `form_object_valid?'
    /Users/jeffdickey/src/rails/meldd/prolog-use_cases/lib/prolog/use_cases/propose_edit_contribution.rb:79:in `run_steps'
    /Users/jeffdickey/src/rails/meldd/prolog-use_cases/lib/prolog/use_cases/propose_edit_contribution.rb:47:in `call'
    test/prolog/use_cases/propose_edit_contribution_test.rb:214:in `block (3 levels) in <main>'


Finished tests in 0.034799s, 28.7363 tests/s, 0.0000 assertions/s.


1 tests, 0 assertions, 0 failures, 1 errors, 0 skips
$
Jeff Dickey
@jdickey
May 11 2016 17:09
if I'm reading this right, then I am indeed exercising the GitHub-repo version of dry-validation, and it's still giving me the brown middle finger

the method it's bitching about (line 85) is

      def form_object_valid?
        schema = Dry::Validation.Schema do
          key(:proposed_by).required(not_eql?: 'Guest User')
        end
        schema_errors = schema.(@attributes.to_h).messages
        ap [:line_89, schema_errors]
        form_object.valid?
      end

and it never gets as far as the dump-the-schema-errors-to-stderr line near the end

line 85 is where it's assigning to schema
Jeff Dickey
@jdickey
May 11 2016 17:17
pinging @fran-worley; I'll be back on in 10 hours or so, but it's 0115 here and I'm toast for the day. Thanks again, and catch you all later.
Fran Worley
@fran-worley
May 11 2016 17:38
@jdickey I'll comment on your gist if/ when I come up with anything
Phil Schalm
@pnomolos
May 11 2016 17:49
@timriley I’m working on dry-types-rails (to deal with the autoloading crap) and I’m wondering if I could get your input. Obv. due to the overloading a subclass of Struct will be registered multiple times, and while I can hook in I’m unsure on what the best behaviour would be. If I catch the exception won’t the registration still be pointing at the previous version of the class? Haven’t played with unloading of constants enough to grasp what would be happening.
Tom Willis
@twillis
May 11 2016 18:48
hi all, is anyone aware of a more complete example of injecting external dependencies in dry-validation? http://dry-rb.org/gems/dry-validation/basics/working-with-schemas/
Fran Worley
@fran-worley
May 11 2016 19:06
@AMHOL don't you want required(:email).filled ?
Andy Holland
@AMHOL
May 11 2016 19:06
@fran-worley probably
Still haven't actually used dry-validation yet lol
Tom Willis
@twillis
May 11 2016 19:07
thanks @AMHOL if I needed a predicate that needed to take 2 keys into consideration would that be a rule? For example, the unique email example, if the email it found belonged to the user with that id, then unique? wouldn't need to fail.
Fran Worley
@fran-worley
May 11 2016 19:08
@AMHOL Any thoughts on gem dependencies. dry-validation is pulling dry-logic and dry-types from master for development but when you install it as a gem it appears to install logic and types versions not master. I don't know enough about bundler to work out a way around it and as far as I know only @solnic has access to ruby gems to release new versions...
Andy Holland
@AMHOL
May 11 2016 19:10
@twillis it would in a real-world use case if the repository implemented updates
Yeah, that would be a rule AFAIK, @fran-worley ?
@fran-worley I think Solnic gave me and Tim access too
The only way that I'm aware of would be to specify all of the dependencies from git/github in the gemfile
You want me to release them?
Fran Worley
@fran-worley
May 11 2016 19:11
@twillis @AMHOL Yup you need a rule
@AMHOL can you release dry-logic and dry-types then I'll update the gemspec in dry-validation
@AMHOL the gemfile only seems to assist in development. When bundler resolves dependencies on install it seems to install the version per the gemspec not the gemfile
Tom Willis
@twillis
May 11 2016 19:13
any chance I can get an example of how that would work? I have code but the function is getting passed Dry::Validation::Schema::Check's and I would need the value from those
Andy Holland
@AMHOL
May 11 2016 19:13
Ahh OK
Fran Worley
@fran-worley
May 11 2016 19:17
@twillis reading your example I'll post something for you in a sec
Tom Willis
@twillis
May 11 2016 19:18
cool thanks so much
Fran Worley
@fran-worley
May 11 2016 19:27
@twillis did you send something to @AMHOL to inspire his gist?
Fran Worley
@fran-worley
May 11 2016 19:28
@twillis I know I was wondering what inspired it...
Tom Willis
@twillis
May 11 2016 19:29
oh my question inspired it. i can probably post what I have if you like. though you'll have to ignore the "prorietary bits"
Fran Worley
@fran-worley
May 11 2016 19:30
@twillis that would be helpful, there are a couple of ways of doing it. I personally have set my uniqueness finder to exclude the current record (if persisted) but you could also use a rule
darn should have unwound my debugging first :P
@fran-worley I can't get into too much detail about what i'm working on, but a lot of the data that comes in from our ui will need to be validated with rules considering many keys and possibly interacting with external systems as part of it. we have it working ok in Veto, but that lib has been abandoned and has annoying quirks. So I'm hoping I can just replace it with dry-validations.
Fran Worley
@fran-worley
May 11 2016 19:36
@twillis no worries I should have enough to help. What version of dry-v are you using?
Tom Willis
@twillis
May 11 2016 19:36
0.7.4
Fran Worley
@fran-worley
May 11 2016 20:46
@/all Just released dry-logic 0.2.3 and dry-types 0.7.2
@jdickey I've also bumped the versions in dry-validations gemspec so can you try re-bundling dry-validation from master and see if that fixes your dependency issue?
Andy Holland
@AMHOL
May 11 2016 20:48
Nice one @fran-worley :)
Fran Worley
@fran-worley
May 11 2016 20:49
@AMHOL I'm sure I made more of a job out of that than I needed to!! Just got to update dry-rb.org now!
Phil Schalm
@pnomolos
May 11 2016 21:27
To those working on dry-types/dry-container. I know it’s “VERY BAD”™, but for the purpose of dealing with Rails autoloader what’s the suggestion on the best way to re-register a type?
Tim Riley
@timriley
May 11 2016 22:09
@fran-worley thanks for the releases - I see you realised that github deps in Gemfile don’t actually work in released gems?
@pnomolos I’m sorry, I’ve never used dry-types in Rails :\
Phil Schalm
@pnomolos
May 11 2016 22:13
@timriley That’s OK, I think I’ve sorted out (most) of the Rails side of thing, just looking for suggestions on re-registering a type without the "There is already an item registered with the key” error :)
Fran Worley
@fran-worley
May 11 2016 22:14
@timriley eventually... I hope you didn't mind I know you've done a lot on dry types recently. Do you have much experience with jruby?
dry-rb/dry-validation#159
Tim Riley
@timriley
May 11 2016 22:15
I have pretty much 0 experience with jruby :grimacing:
@pnomolos all I can think of right now is providing your own custom registry object to dry-container
since that’s where the problem is. as in, that’s where the errors are raised about duplicate registrations.
the registry is a configurable option, so you could provide your own development mode registry that is less concerned about re-registrations
of course, this is changing a relatively important piece of behaviour for the sake of rails class reloading, so take that idea with a grain of salt!
Phil Schalm
@pnomolos
May 11 2016 22:17
@timriley Hmm, that’s an idea I guess. I was going about it the hard way and trying to worm my way down the rabbit hole to overwrite the value with the new class constant ;)
Andy Holland
@AMHOL
May 11 2016 22:49
@pnomolos the last time this was discussed I came up with this monstrosity
There is no "nice" solution though, a custom registry for dry-types' container would be the "best" solution, but either way you go about it, you're potentially going to suppress errors in development that could be present in production
Unless you disable rails code reloading and use another method
Phil Schalm
@pnomolos
May 11 2016 23:01
Yeah, I think it’s going to come with a big caveat about the reloading issue.
Tim Riley
@timriley
May 11 2016 23:05
I don’t always use dry-types, but when I do, I do it in production mode
Andy Holland
@AMHOL
May 11 2016 23:05
:joy:
You could of course use a custom registry regardless of environment
And just let em re-register
Nick Sutterer
@apotonick
May 11 2016 23:09
@fran-worley aahaaaa, this is where you hang out these days!
Phil Schalm
@pnomolos
May 11 2016 23:28
@AMHOL Unfortunately even with that, Dry::Types[klass].primitive retains a reference to the old class
Phil Schalm
@pnomolos
May 11 2016 23:35
@AMHOL Here’s the failing spec - https://gist.github.com/pnomolos/fb7dd1c04cb7f6daefb794fe536d4594 - or maybe I’m overthinking things, but if it’s holding an old reference won’t there exist the possibility for a lookup to return an old version of the class?