Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Roadmap for 1.0 #128

Open
22 tasks done
milessabin opened this issue Apr 5, 2021 · 16 comments
Open
22 tasks done

Roadmap for 1.0 #128

milessabin opened this issue Apr 5, 2021 · 16 comments
Milestone

Comments

@milessabin
Copy link
Member

milessabin commented Apr 5, 2021

@milessabin milessabin added this to the 1.0.0 milestone Apr 5, 2021
@tpolecat
Copy link
Member

tpolecat commented Apr 5, 2021

I think we probably need to get the doc site back in shape as well.

@tpolecat
Copy link
Member

tpolecat commented Apr 5, 2021

Also need to implement subscriptions (in progress).

@milessabin
Copy link
Member Author

milessabin commented Apr 19, 2022

I'm about to land a second rewrite of the SQL compiler. Now landed.

@armanbilge
Copy link
Member

Low-priority, but it would be cool to cross-build for Scala.js as well. It should be easy since all your dependencies are already on Scala.js with identical APIs, except for doobie. However, the tests would be hampered by the testcontainers dependency.

Tangential, but IMHO a library cannot really 1.0.0 in the bincompat sense while it has dependencies that themselves have not 1.0.0-ed (in this case, circe, skunk, etc.). The reason is a breaking version bump in one of those dependencies would force a breaking version bump in your library, so you can only be as binary-stable as your least-stable dependency.

@milessabin
Copy link
Member Author

Cross-building for Scala.js makes sense ... I'll add it to the list.

Point taken about unstable dependencies. The core module doesn't have any unstable dependencies, so maybe we declare 1.0.0 for core, and have the circe/doobie/skunk module versions track the corresponding upstream versions?

@armanbilge
Copy link
Member

Huh, core also seems to depend on circe, as well as cats-parse.

https://github.com/gemini-hlsw/gsp-graphql/blob/79f2b1cc9e2f541b203d2902014f173bfaa5447a/build.sbt#L84-L100

@milessabin
Copy link
Member Author

Hmm ... that could probably be eliminated. It's only used internally, mainly to generate result Json, and it's probably not the most efficient way of doing that, so a faster, stable, alternative might be a better option.

@milessabin
Copy link
Member Author

@armanbilge added a couple of issues to reflect your comments: #202, #203.

@milessabin
Copy link
Member Author

milessabin commented May 26, 2022

@armanbilge I think we have to stick with cats-parse. I think on balance I'd be happy to bump Grackle's major version number if we need to update cats-parse before it reaches 1.0.0.

@jf-botto
Copy link
Contributor

Hi,
I'm always looking for open source things to work on and I'd like to help out. Would anyone mind if I worked on #197 or #199? I'm more than happy to look at any other small/self contained issues that might be more useful/appropriate.

@milessabin
Copy link
Member Author

@jbotto94 sorry, I missed your message earlier. Both #197 and #199 are real chores and a bit fiddly ... I wouldn't want to inflict them on you. How about #237? It involves digging around in the query algebra and the various places it's used ... I think it'll be a lot more interesting and give more insight into how Grackle hangs together.

@jf-botto
Copy link
Contributor

@jbotto94 sorry, I missed your message earlier. Both #197 and #199 are real chores and a bit fiddly ... I wouldn't want to inflict them on you. How about #237? It involves digging around in the query algebra and the various places it's used ... I think it'll be a lot more interesting and give more insight into how Grackle hangs together.

Sure :). Wasn't sure if you had started working on it or not.

@armanbilge
Copy link
Member

armanbilge commented Aug 29, 2022

@milessabin here's another one to add to the list: you should probably replace the log4cats-slf4j dependency with just log4cats-core and ask for a LoggerFactory constraint. Users can then import an implicit Slf4jLoggerFactory to satisfy it.

https://github.com/gemini-hlsw/gsp-graphql/blob/6d4223acc817de01c13e32e75091d6f6712835f3/build.sbt#L125

A few motivating reasons:

  1. slf4j recently released a 2.0 and the implications are not yet clear. Dodging the dependency altogether is a good strategy.
  2. There maybe be other log4cats backends in the near future, such as otel4s.
  3. slf4j is not available for Scala.js or Scala Native. Depending on it will force that code to be split when we cross-compile.

@milessabin
Copy link
Member Author

@armanbilge I think log4cats-slf4j should only be a test dependency.

@milessabin
Copy link
Member Author

@armanbilge apropos SLF4J, see #404.

@milessabin
Copy link
Member Author

We're pretty much done! 🎉

I do want to get #258 in as well though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants