Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jun 29 05:06
    stanislav-chetvertkov synchronize #1510
  • Jun 29 04:56
    stanislav-chetvertkov synchronize #1510
  • Jun 28 18:53
    stanislav-chetvertkov synchronize #1510
  • Jun 28 15:50
    github-actions[bot] labeled #1510
  • Jun 28 15:50
    github-actions[bot] labeled #1510
  • Jun 28 15:50
    github-actions[bot] labeled #1510
  • Jun 28 15:37
    stanislav-chetvertkov opened #1510
  • Jun 26 19:44

    github-actions[bot] on scala-akka-http-v0.74.0

    (compare)

  • Jun 26 19:44

    github-actions[bot] on scala-http4s-v0.74.0

    (compare)

  • Jun 26 07:08

    github-actions[bot] on scala-support-v0.74.0

    (compare)

  • Jun 26 07:01
    blast-hardcheese labeled #1509
  • Jun 26 07:01

    blast-hardcheese on master

    Fixup to the last PR, refined w… Temporarily removing Build.scal… Merge pull request #1509 from b… (compare)

  • Jun 26 07:01
    blast-hardcheese closed #1509
  • Jun 26 06:53
    blast-hardcheese labeled #1509
  • Jun 26 06:45
    blast-hardcheese opened #1509
  • Jun 26 06:39
    blast-hardcheese labeled #1508
  • Jun 26 06:39
    blast-hardcheese labeled #1508
  • Jun 26 06:38
    blast-hardcheese commented #1299
  • Jun 26 06:37

    blast-hardcheese on master

    refined types Removing extraneous validation … a separate module for circe-ref… and 3 more (compare)

  • Jun 26 06:37
    blast-hardcheese closed #1508
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
kelnos: Yeah, maintainability needs to continue to be good. What about a version.sbt per module, all as subprojects in the main guardrail repo?
some magicks for checking to see if the current version has already been published and skipping if so
kelnos
@kelnos:matrix.org
[m]
if that's something you can do, sure
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
I believe that's possible to do with sbt
trying to think of what the implications of the current release flow through the github UI would be though
I really like the release-notes -> publish workflow
might need to write a custom github action :\
also, all this is moot if I can't come up with a good UX for consumption from sbt/maven/gradle
kelnos
@kelnos:matrix.org
[m]
also maybe a little worried about what kind of soup the git tags will look like
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
mmyeah. It'd end up turning into a grid of gems
a plus would be extensions to guardrail core would just be able to be natively supported directly in the build tooling though
something like <modules><module><name>http4s</name><clientClass>dev.guardrail.generators.ScalaGenerator.Http4sClientGenerator.ClientTermInterp</clientClass>... where the fqcn's are able to be specified (with sensible defaults) in the pom.xml, and so long as the codegen phase has those dependencies on the classpath everything comes together
kelnos
@kelnos:matrix.org
[m]
that'd be kinda cool
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
thinking ahead, that could open modules up to the community without having to choose which build tool plugin has the features you want.
hah, for instance, circe-java8 could be spun out without just hanging on in the core forever
this is a big change, I'll write something up and open it as an issue
first though, I'll see whether the UX is compelling.
kelnos
@kelnos:matrix.org
[m]
sounds good
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
LOL sbt is really flexible.
+val myCustomHttp4sThing = modules.http4s.client.copy(
+  newGetExtraImports={ tracingEnabled =>
+    import scala.meta._
+    dev.guardrail.Target.pure(List(q"import dev.guardrail.example"))
+  }
+)
 lazy val exampleClient = (project in file("example-client"))
   .settings(commonSettings)
   .settings(
-    Compile / guardrailTasks += ScalaClient(file("server.yaml"), pkg="example.client", framework="http4s"),
+    Compile / guardrailTasks += ScalaClient(file("server.yaml"), pkg="example.client", framework="http4s").modules(myCustomHttp4sThing, _.circe.json),
     libraryDependencies ++= commonDependencies
   )
damn
talk about flexibility and empowering users to work around bugs
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
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