Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 04:45
    github-actions[bot] labeled #1488
  • 04:45
    github-actions[bot] labeled #1488
  • 04:22
    scala-steward opened #1488
  • 02:26
    github-actions[bot] labeled #1487
  • 02:26
    github-actions[bot] labeled #1487
  • 01:21
    scala-steward opened #1487
  • May 20 04:48
    github-actions[bot] labeled #1486
  • May 20 04:48
    github-actions[bot] labeled #1486
  • May 20 04:48
    github-actions[bot] labeled #1486
  • May 20 04:41
    scala-steward opened #1486
  • May 19 17:05
    github-actions[bot] labeled #1485
  • May 19 17:05
    github-actions[bot] labeled #1485
  • May 19 16:23
    scala-steward opened #1485
  • May 19 13:52
    github-actions[bot] labeled #1484
  • May 19 13:47
    blast-hardcheese closed #1466
  • May 19 13:22
    scala-steward opened #1484
  • May 18 19:37
    github-actions[bot] labeled #1483
  • May 18 19:37
    github-actions[bot] labeled #1483
  • May 18 19:29
    scala-steward commented #1466
  • May 18 19:29
    scala-steward opened #1483
Nick Hudkins
@nickhudkins
@blast_hardcheese:matrix.org you've inspired me
sangria-graphql/sangria-akka-http#12 (I'm sorry for straying from REST, I hope you will forgive me)
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
@nickhudkins No apologies necessary! We use Sangria at work, thanks for everything you guys do!
Nick Hudkins
@nickhudkins
Thatโ€™s fantastic to hear! We lost Oleg (the original author) about two years ago. Extremely sad, and so we are still trying to catch up. He was incredibly brilliant and capable. I wish I knew the internals even more. We should talk! Iโ€™d love to hear your experience with it.
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
Oh. I'm really sorry to hear that, and certainly, I'd love to help. I've been spending some time in caliban codegen recently, and abusing Sangria by just doing rest over GraphQL ๐Ÿ˜…
Shanan Sussman
@myfancypants

So i'm working on upgrading an older service onto the latest version of guardrail. One of the generated clients in particular seems to trip up the compiler complaining about unused imports for AkkaHttpImplicits.scala and Implicits.scala, but when compared to a seemingly similar client with the same code-gen created for those file. There aren't any warnings.

I know i could just surpress the warnings, but i'm more confused as to how one client is fine, but the other triggers warnings

blast_hardcheese
@blast_hardcheese:matrix.org
[m]
I think this could be due to a number of different reasons -- the types of parameters used in either client being the most likely answer, I think.
Shanan Sussman
@myfancypants
interesting
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
in an ideal world, we'd register features utilized as we walked the codegen and do explicit imports for distinct features.
Unfortunately, for x-jvm-type: ..., since it gives the capability to use absolutely anything that's supported either by guardrail internally or by your own extensions, so there's no guarantee which imports would be used or not.
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
scalac has support for just excluding warnings for specific paths, you can see https://alexn.org/blog/2020/05/26/scala-fatal-warnings.html for a random example of what I found when googling.
scalacOptions ++= Seq(
  "-Wconf:src=src_managed/.*:silent",
)
Shanan Sussman
@myfancypants
yeah, was just hoping to avoid that, for whatever reason i've never noticed the warnings before in other services. Wonder if we had just suppressed them by default already or something
but c'est la vie
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
you know how I always aim to please, Shanan, I'm sorry to let you down here.
Shanan Sussman
@myfancypants
don't stress it buddy, in some ways this is better as i can stop looking into understanding why there's a difference :P
oh yeah, we've definitely just been excluding it in other systems
<arg>-Xlint:-unused,_</arg>
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
boom
The -Wconf:src=... option would be preferred, as it would only exclude unused in generated sources
what guardrail may be able to do is automatically add an explicit -Wconf:src, since we actually know exactly which directories we generated into
that would certainly improve usability
Shanan Sussman
@myfancypants
that sounds ideal, since preventing unused imports within application code is something i'd like to keep
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
certainly. I can't look at this right now, as my time is allocated towards the modularization proposal, ramping up to the 1.x release, but if you want to test swapping that -Xlint:-unused,_ for -Wconf:src:..., that would be a step in the right direction
Shanan Sussman
@myfancypants
might have to come back to that, looks like it was added in 2.13, might need to just get the system to build + bake, before i take the step of upgrading scala versions. The changes are already including bumping from java 8 to 11
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
oh, please disregard then, I didn't realize it was so new
it may not end up being worth it at all anyway, as a lot of warnings were removed in dotty (much to my displeasure)
it'll be interesting to see how things shake out as people start moving production systems to dotty
Shanan Sussman
@myfancypants
is dotty the same as 3.0 or a different fork of scala? I can never remember
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
Yeah, dotty became 3.0
I should start just saying 3.0
Shanan Sussman
@myfancypants
:pewpew:
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
There are only two other forks of Scala I know of, the typelevel fork as well as a paid super optimized one with some kind of other really cool features
the fragmentation all comes from how many different major/minor revisions people are using ๐Ÿ˜•
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
kelnos: Barring any major objections to guardrail-dev/guardrail#1197 I think I'll merge as-is -- I was thinking it would make sense to also re-package definitions and modules and whatnot, but that'll be a real PITA for folks who maintain their own forks of guardrail to do all at once.
Once that's in, I'll cut some smaller PRs to move individual classes to raise visibility and make each individual changeset tractable, instead of doing 52 card pickup with the package structure.
The nice thing about wrapping this splitout up with guardrail_${scala.binary.version} artifact as root is that it's a no-op for the build tools at the moment, we can gradually implement the tooling improvements when there's time
once all the pieces are in place, I think the last big thing is to remove the tracing stuff, as akka-http, http4s, dropwizard, and spring-mvc all have a better way of doing that, either by mapRoute or by mapping over the entire server itself, and for the Java servers my understanding is there's deep introspection modules that can be registered to provide the route-level tracing required
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
if I'm wrong about that I'm happy to revise, but I don't believe the tracing stuff has ever been broadly consumable other than the bespoke stuff in Twilio's scala-service overrides.
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
also, hah, it has been a while since trying to use metals from vim
kelnos
@kelnos:matrix.org
[m]
blast_hardcheese: fine by me, probably won't have time to look into it in any detail all that soon
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
Understood, just wanted to make sure you were broadly OK with the direction
kelnos
@kelnos:matrix.org
[m]
agree on the tracing stuff, i think it probably should have been out of scope for guardrail in the beginning, but yeah, was mostly there for the twilio bits (that we don't use anymore anyway)
might want to write up a migration guide, though, in case anyone's using it
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
Yeah, as well as a class/package remapping list as things progress in that direction.
The splitout kind of lends itself towards moving stuff like ClientGenerator and ServerGenerator over in dev.guardrail.generators next to ProtocolGenerator, as well as to clean up all the cross-references between those things (like how akka-http uses the response generators from http4s)
kelnos
@kelnos:matrix.org
[m]
i think i would go for something like dev.guardrail.generators.{protocol, server, client} with perhaps also a helpers package
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
What do you think about guardrail-core being reflected in dev.guardrail.core.{...}?
or would dev.guardrail.{...} be the de-facto core?
kelnos
@kelnos:matrix.org
[m]
hrm, i don't think i see the need for a core package, but i'm not really against it either