Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 19 21:58
    blast-hardcheese commented #1342
  • Jan 19 21:57
    blast-hardcheese commented #1342
  • Jan 16 17:53
    blast-hardcheese closed #1325
  • Jan 16 10:54
    zeal18 commented #1342
  • Jan 15 18:08

    blast-hardcheese on master

    Update slf4j-simple to 1.7.33 Merge pull request #1376 from s… (compare)

  • Jan 15 18:08
    blast-hardcheese closed #1376
  • Jan 15 08:43
    codecov[bot] commented #1376
  • Jan 15 08:42
    codecov[bot] commented #1376
  • Jan 15 08:42
    codecov[bot] commented #1376
  • Jan 15 08:42
    codecov[bot] commented #1376
  • Jan 15 08:42
    codecov[bot] commented #1376
  • Jan 15 08:42
    codecov[bot] commented #1376
  • Jan 15 08:41
    codecov[bot] commented #1376
  • Jan 15 08:41
    codecov[bot] commented #1376
  • Jan 15 08:27
    blast-hardcheese synchronize #1325
  • Jan 15 08:26
    blast-hardcheese closed #1355
  • Jan 15 08:25
    codecov[bot] commented #1376
  • Jan 15 08:25
    codecov[bot] commented #1376
  • Jan 15 08:25
    blast-hardcheese synchronize #1376
  • Jan 15 08:24
    blast-hardcheese synchronize #1375
blast_hardcheese
@blast_hardcheese:matrix.org
[m]

So an interesting side effect of the module system that I hadn't considered, when a release-drafter release is cut, the tag is minted immediately. This has the effect of all subsequent runs compiling against the ABI exposed by the compiled modules in the source trees, but publishing POMs that refer to the tagged module versions.

The implications of this are that so long as you click release on the various drafts in the reverse-depends order, you can just release everything at once, and as the modules trickle up to bintray, they'll all be pointing at the right versions of stuff

the downside is that this isn't obvious, so if core's ABI breaks but it isn't released, then something that depends on core is released, it will be compiled against the new ABI but depend on the previous ABI.
The upside is that this all still happens at compile-time, not at runtime, so any goofs here manifest as inconveniences for the users, not runtime incidents.
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
kelnos Holy moly. The classloader stuff was annoying to work around. Much more so than I anticipated due to the strictness of classloading block members. I needed an indirection class in order to get it to work at all, but what I ended up with ends up with all the core deps being included in sbt-guardrail and friends, but by default if you try to use anything, you end up getting
sbt:guardrail-sample-http4s> compile
Missing dependency: guardrail-scala-http4s
[error] (Compile / guardrail) dev.guardrail.sbt.CodegenFailedException
[error] Total time: 0 s, completed Oct 14, 2021 6:31:52 PM

If I then stick

libraryDependencies += "dev.guardrail" %% "guardrail-scala-http4s" % "0.65.3-8-ga447b33-SNAPSHOT"

into project/plugins.sbt, it runs and generates sources, compiling successfully

Can you think of anything at a high level that I'm blundering into here, or does this still make sense enough to you that I'm not going to just crash this whole thing into the ground?
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
I did some analysis to track how classes were split into the various modules, as well as repackaging, as well as inner classes being moved to new objects: https://gist.github.com/blast-hardcheese/1c4dcfe2151510dfc87ec8e384d87cd1
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
Snapshots of the above have been published, things look good so far.
// Stick this in your project/guardrail.sbt or project/plugins.sbt, wherever you currently have the guardrail addSbtPlugin
resolvers += "Sonatype OSS Snapshots" at "https://s01.oss.sonatype.org/content/repositories/snapshots"
addSbtPlugin("dev.guardrail" % "sbt-guardrail" % "0.65.4+4-8fd0a0c5+20211015-1748-SNAPSHOT")

// stick these alongside the addSbtPlugin in whatever file you ended up using above
libraryDependencies += "dev.guardrail" %% "guardrail" % "0.65.4-31-g5de1766-SNAPSHOT"
libraryDependencies += "dev.guardrail" %% "guardrail-cli" % "0.65.1-31-g5de1766-SNAPSHOT"
libraryDependencies += "dev.guardrail" %% "guardrail-core" % "0.65.3-31-g5de1766-SNAPSHOT"
libraryDependencies += "dev.guardrail" %% "guardrail-java-async-http" % "0.65.1-31-g5de1766-SNAPSHOT"
libraryDependencies += "dev.guardrail" %% "guardrail-java-dropwizard" % "0.65.1-31-g5de1766-SNAPSHOT"
libraryDependencies += "dev.guardrail" %% "guardrail-java-spring-mvc" % "0.65.1-31-g5de1766-SNAPSHOT"
libraryDependencies += "dev.guardrail" %% "guardrail-java-support" % "0.65.1-31-g5de1766-SNAPSHOT"
libraryDependencies += "dev.guardrail" %% "guardrail-scala-akka-http" % "0.65.1-31-g5de1766-SNAPSHOT"
libraryDependencies += "dev.guardrail" %% "guardrail-scala-dropwizard" % "0.65.1-31-g5de1766-SNAPSHOT"
libraryDependencies += "dev.guardrail" %% "guardrail-scala-endpoints" % "0.65.1-31-g5de1766-SNAPSHOT"
libraryDependencies += "dev.guardrail" %% "guardrail-scala-http4s" % "0.65.3-31-g5de1766-SNAPSHOT"
libraryDependencies += "dev.guardrail" %% "guardrail-scala-support" % "0.65.1-31-g5de1766-SNAPSHOT"
Start with just the plugin, then add whichever the plugin tells you that you need
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
guardrail-dev/guardrail#1300 starting to make it easier for iterating on a single module. Might be useful to .aggregate(dependents % "test") when working on a module to ensure related modules' tests also get run
kelnos
@kelnos:matrix.org
[m]
blast_hardcheese: sorry i've been MIA for a bit... this all seems reasonable from an implementation perspective (the indirection classes are kinda ugly, but not sure there's a way around that). my main concern is that now the build/plugin configuration is significantly more complicated for the user.
kelnos
@kelnos:matrix.org
[m]
mmm, true
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
OK. I've done another pass at the provided switchup, I think it's more stable now. The last time I tried publishing it introduced ABI incompatibilities, after a bit of back and forth I convinced SBT to use explicitly published jars when building release artifacts, which should make everything more stable overall.
Ondra Pelech
@sideeffffect
Currently, we use Guardrail to generate both Server and Client part, but the generated code ends up in separate *.server and *.client packages. Is there a way to generate only the shared data structures -- so that we could create shared functionality for them, like validators, etc -- that would be used by both Server and Client?
kelnos
@kelnos:matrix.org
[m]
@sideeffffect: pretty sure the package names are coming from your configuration, not anything hard-coded in guardrail itself
Ondra Pelech
@sideeffffect
But won't there be a conflict if I try to generate both Server and Client to the same package? Also, if I want to have a JAR with the shared data-structures that is to be then depended upon by both Server and Client, how do I do that?
kelnos
@kelnos:matrix.org
[m]
we're generally very careful to not generate the same class names in clients and servers. the only thing that will get generated twice is the stuff under definitions, but, given the same spec, they will always be the same between clients and servers
Ondra Pelech
@sideeffffect
I see -- so the solution is to generate both Server and Client to the same package and thus there will be just one set of shared Data structures. Rigth?
kelnos
@kelnos:matrix.org
[m]

Also, if I want to have a JAR with the shared data-structures that is to be then depended upon by both Server and Client, how do I do that?

you more or less can't, at least not without some gymnastics. you could generate in models mode (as opposed to client or server) in one module, and that will give you definitions. then in the other modules you depend on that, and generate in client or server mode. but that will still generate a duplicate definitions package, so you'll have to figure out how to delete them after generation

that's not really the way most people use guardrail; the general idea is not to ship binaries based on the openapi spec at all. you ship the openapi spec, and your users generate the client themselves, using whatever tool/framework/whatever they prefer. but i do understand that some people want to ship fully-functional clients as a jar. it's just not as common, and it's a little more difficult to do properly. also not sure why you need the separate jar for the definitions, since the server will usually not use the client, and you usually don't need to ship a server. but i figure there are likely use cases i haven't thought of...
(or rather, i should say, shipping a client jar isn't difficult if you just include the definitions and client in the same module/jar)
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
@sideeffffect: If you're using http4s, up until 0.68.0 there was a name collision between server and client generated members, though that was resolved in https://github.com/guardrail-dev/guardrail/releases/tag/scala-http4s-v0.68.0
Ondra Pelech
@sideeffffect
Good to know! Thanks
Stanislav Chetvertkov
@stanislav-chetvertkov

Hi, is there a simple fix for cases where the protocol field names contain reserved words? for example

  schemas:
    MacroWrapper:
      type: object
      required:
        - macro
      properties:
        macro:
          $ref: "#/components/schemas/ZendeskMacro"

gives macro is now a reserved word; usage as an identifier is disallowed, I don't want to use the x-jvm-typeor x-scala-type extensions as a workaround because it would introduce unnecessary complexity.
If there is no fix for this yet (I'm on version 0.64) I could create an issue and for on a fix

blast_hardcheese
@blast_hardcheese:matrix.org
[m]
@stanislav-chetvertkov: I believe guardrail-dev/guardrail#438
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
Actually, more importantly, scalameta/scalameta@ca0de48 which will have been merged in a scalameta upgrade in guardrail, will cause macro to be surrounded in backticks, like other reserved words
so if you can upgrade to a newer version of guardrail internally, that would be preferable.
Additionally, the new repository modularization work will mean that providing modules for Twilio-internal generators (scala-service, twilio-scala-dropwizard) will vastly reduce the amount of code that will need to be maintained. That being said, as much as I have tried to avoid using SPI, I think it would be preferable to use an SPI mapping for guardrail modules, otherwise you are relying on library eviction or pinning
Stanislav Chetvertkov
@stanislav-chetvertkov
Thanks Devon, I'm currently trying to restructure the twilio guardrail repo - it hasn't been updated since 0.64 and its quite a lot of work but we are getting there
3 replies
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
One thing I've been considering is removing the tracing boolean, as it is better served by way of composition now that mapRoutes exists in a number of frameworks. I would like to do this in a way that doesn't break Twilio, so if you know people are still using that feature directly, I can come up with a migration strategy.
1 reply
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
(it was possible before, though would have been more difficult due to the dependency chain)
kelnos
@kelnos:matrix.org
[m]
yeah, i suggested that we should kill the submodule and start depending on the built artifacts. i'm just afraid that anything else will be a difficult maintenance burden later. unfortunately i haven't had the time to look at it myself
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
Yeah, that's what I had in mind as well. Good to see we're on the same page