Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Aug 10 19:36
    stanislav-chetvertkov commented #77
  • Aug 10 15:51
    TonioGela commented #195
  • Aug 10 15:29
    dvgica commented #195
  • Aug 10 15:17
    github-actions[bot] labeled #1555
  • Aug 10 15:17
    github-actions[bot] labeled #1556
  • Aug 10 15:06
    scala-steward closed #1547
  • Aug 10 15:06
    scala-steward commented #1547
  • Aug 10 15:06
    scala-steward opened #1556
  • Aug 10 15:06
    scala-steward closed #1554
  • Aug 10 15:06
    scala-steward commented #1554
  • Aug 10 15:06
    scala-steward opened #1555
  • Aug 10 14:37
    TonioGela commented #195
  • Aug 08 14:22
    github-actions[bot] labeled #1554
  • Aug 08 14:22
    github-actions[bot] labeled #1554
  • Aug 08 14:06
    scala-steward opened #1554
  • Aug 07 05:22

    blast-hardcheese on master

    Update hibernate-validator to 6… Merge pull request #1552 from s… (compare)

  • Aug 07 05:22
    blast-hardcheese closed #1552
  • Aug 05 01:13
    blast-hardcheese commented #1548
  • Aug 04 15:57
    blast-hardcheese commented #1550
  • Aug 04 15:51
    alexklibisz commented #1550
Nick Hudkins
@nickhudkins
sbt-guardrail PR open :)
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
lol, spent an hour trying to figure out why sbt-sonatype wasn't picking up my credentials before I discovered that it sneakily caches the result of sonatypeProfiles in target/, without any sort of eviction if you fix the problem.
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
sbt-guardrail 0.64.4 released, matching the dev.guardrail package shift.
For the next few releases, I'm going to override the organization back to com.twilio and publish the same version to both, to give an opportunity for scala-steward to prompt for upgrades to a version that also prints a warning about the organization change
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
kelnos: What would you say to splitting the guardrail library into different individual modules? Something like guardrail-circe, guardrail-http4s, guardrail-dropwizard, or otherwise? A problem I'm trying to solve is to stop the seeming runaway train that is attempted semver split across so many subprojects
guardrail core really doesn't change too terribly much, and splitting the modules out would reduce the number of no-op PRs opened by scala-steward and friends
like http4s may not change at all, but akka changes a bunch or vice versa, and the other party is just going along with the updates because it might impact them
It might make sense to do guardrail-${language}-${library} as well
with the further added benefit of making each individual codebase more tractable for contributors.
kelnos
@kelnos:matrix.org
[m]
blast_hardcheese: sounds like that could help, but i'm worried about it all being more annoying to release, and also during development when making core changes that are then used in the generators
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>