Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Nickolay Kudasov
    @fizruk
    But you can always just ask and we'll respond when we have time to :)
    Thomas Crevoisier
    @ThomasCrevoisier
    yup of course :)
    Is there some documentation specifying the difference between Swagger2 and OpenAPI 3 ? Making the diff between those specs will be a bit cumbersome :P
    I hacked a bit the lib yesterday to get familiar. The only thing I struggled for the moment was modifying the instance FromJSON Schema because of the generic parser
    Nickolay Kudasov
    @fizruk
    hmm
    there was a blog explaining differences
    but it's unavailable for some reason (not even via Google's webcache)
    but there's a YouTube video with that article: https://www.youtube.com/watch?v=rF2xgpdscYU
    It has been published before the official release, but is probably mostly accurate
    of course the most reliable source would be to read OpenAPI 3 docs directly: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md
    but I agree that it's a bit cumbersome
    I remember reading through Swagger 2.0 spec many times to try to understand what they mean
    Thomas Crevoisier
    @ThomasCrevoisier
    Okay thanks
    Thomas Crevoisier
    @ThomasCrevoisier
    For supporting new operators (oneOf and so on), the idea would be to have a Schema data type for OpenAPI and one for Swagger2 ?
    I'm a bit confused how to make a clean transition
    Nickolay Kudasov
    @fizruk
    yes, I think we've settled on coping the whole Data.Swagger module to Data.OpenAPI or better Data.OpenAPI3 or Data.OAS3
    and then we would modify that new module hierarchy
    Thomas Crevoisier
    @ThomasCrevoisier
    By Data.Swagger I suppose you also includes Data.Swagger.* submodules ?
    Nickolay Kudasov
    @fizruk
    yes, the whole hierarchy
    there are a few common/utility modules
    those we probably want to have in Data.OpenAPI.Common or something
    Thomas Crevoisier
    @ThomasCrevoisier
    Yep okay
    I'll try to make a PR soon
    Thomas Crevoisier
    @ThomasCrevoisier
    Quick question about the current lib. I struggle to add a description on a referenced schema, is there an example of such thing ?
    Nickolay Kudasov
    @fizruk
    Referenced Schema?
    it's not trivial to add anything to that, because you need (mutable) context — definitions
    Thomas Crevoisier
    @ThomasCrevoisier
    hum, maybe it's not the good way to do it. Basically my type is a record and I want to add a description on one field
    Nickolay Kudasov
    @fizruk
    why do you want to modify Referenced Schema?
    you can inline field definition and update that
    if I understood correctly your goal
    Thomas Crevoisier
    @ThomasCrevoisier
    yup
    Nickolay Kudasov
    @fizruk
    something like...
    declareNamedSchema proxy = genericDeclareNamedSchema proxy
   & mapped.schema.properties.at "my_field" .~ updatedFieldSchema
  where
    updatedFieldSchema = toSchema (Proxy :: FieldType)
      & description ?~ "Field description"
    this approach is not very elegant since it requires you to know property name
    i.e. "my_field"
    Thomas Crevoisier
    @ThomasCrevoisier
    yep
    I think it's acceptable enough for my use case though
    Nickolay Kudasov
    @fizruk
    but you need to know that one anyway :)
    a better approach might be to wrap that field in a newtype with a customized instance...
    but then you'd need to deal with an extra wrapper
    Thomas Crevoisier
    @ThomasCrevoisier
    I'm not comfortable with lens and optics in general yet, so I struggle a bit ^^
    Nickolay Kudasov
    @fizruk
    most probably you don't want extra wrapper just for description
    Thomas Crevoisier
    @ThomasCrevoisier
    I thought about the newtype instance, I don't know yet how the code will evolve but the field would probably become a specific type, so the problem will be solved :)
    thanks for your help !
    Dinkar Ganti
    @dservgun

    Hi. I am trying to build swagger2 for haskell : (https://hackage.haskell.org/package/swagger2) and am facing the following error. I didn't realize that this was a general lobby for swagger.

    - generics-sop-0.5.1.0@sha256:69b1f74cd97a96d060f745fc6052e6895089a563eddfb7f118f82a63f5497794,5646

    The issue seems to be that the stack.yaml is using

    resolver: lts-15.1

    The resolver that seems to work is with 16.13? Is anyone else facing this issue? Thanks.