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

Remove scala-reflect from compile-time dependencies #326

Closed
adamw opened this issue Jul 9, 2021 · 8 comments · Fixed by #338
Closed

Remove scala-reflect from compile-time dependencies #326

adamw opened this issue Jul 9, 2021 · 8 comments · Fixed by #338
Labels

Comments

@adamw
Copy link
Member

adamw commented Jul 9, 2021

It is pulled in transitively via mercator. Instead, it should be marked as provided.

Maybe it would be possible to remove the mercator dependency alltogether?

@adamw adamw added the scala2 label Jul 9, 2021
@joroKr21
Copy link
Contributor

I see a couple of options for removing mercator:

  • Roll our own Monad or better yet Applicative type class
  • Have constructMonadic take polymorphic pure and flatMap functions as arguments
  • Remove constructMonadic altogether (does it exist for Scala 3?)

@KacperFKorban
Copy link
Collaborator

In Scala 3 we have our own Monad. It was supposed to be a temporary solution.

@adamw
Copy link
Member Author

adamw commented Jul 13, 2021

I think having a self-contained project w/ a Monad/Monadic construct would be the most user-friendly version. There is constructMonadic in the scala3 version, but without a dependency on mercator (or any other dependency)

@joroKr21
Copy link
Contributor

That will break binary compatibility again 😞

@joroKr21
Copy link
Contributor

I'm not sure we can even update Mercator without breaking binary compatibility

@adamw
Copy link
Member Author

adamw commented Sep 1, 2021

@joroKr21 We're changing the group id, the package, so until we release 1.0 I don't think binary compatibility is a problem? Quite the contrary, now is the time to break things, no? :)

@joroKr21
Copy link
Contributor

joroKr21 commented Sep 1, 2021

Quite the contrary, now is the time to break things, no? :)

On the one hand yes, but on the other hand users still complain when it's broken: #266
The problem is that Magnolia is very close to the dependency root.

@adamw
Copy link
Member Author

adamw commented Sep 1, 2021

@joroKr21 but that's 0.17, 1.0 will never be a drop-in replacement for 0.17, 0.16 or any other version, even if it's only because of the new package name :)

@ghost ghost linked a pull request Sep 19, 2021 that will close this issue
@adamw adamw closed this as completed Sep 23, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants