eed3si9n
Deduplicate with Verify?
https://github.com/scala/nanotest-strawman contains some version of Expecty inside. Since there isn't much point in keeping two code bases, I am thinking we should fold any changes we made in this repo into Verify (or bring Verify code here) so they are always in sync. We can still produce Expecty-only JAR.
/cc @keynmol, @Baccata, @SethTisue
If it makes your life easier and as long as there remains an expecty-only jar, I'm not opposed to it
I feel like MUnit has now firmly lodged itself in the niche that Verify was intended to occupy, so I doubt it makes sense to intertwine the futures of expecty (which I think has a bright future) and verify (which I'm pretty sure doesn't)
why doesn't verify have expecty as a dependency, why is in-sourced there?
why doesn't verify have expecty as a dependency, why is in-sourced there?
As you might recall, the original vision of Verify was to be a basic, zero-dependency unit testing library living in scala/scala, and published to together with scala-library, or scala-compiler so we don't have to wait around for the ScalaTest or ScalaCheck to be available esp during binary incompatible milestones - https://github.com/scala/scala-dev/issues/641. Given that Scala 3.x maintains backward compatibility, I would concede there's less need to include a unit test as a standard module, but now that Verify was made, I consider it to be somewhat done (sans Scala 3 macro issues common to Expecty).
I personally benefit from Verify 1.0's wide build matrix for testing Scopt etc. I back published Verify 1.0.0 for Scala 3 support on Scala Native the day it came out (https://twitter.com/eed3si9n/status/1484976260996640775) thanks to contributors. MUnit doesn't support it as of this writing.
The problem that I see it is that the most useful part assert(...) macro, is also the buggy part that would benefit from further upkeep going forward, and potentially keeping up with the evolution of Scala 3 metaprogramming. Having a common code base between Verify and Expecty mutually benefits each other IMO, since Expecty code would be tested in any project that might use Verify, and anyone not interested in the unit testing part can use Expecty.
Okay. As @Baccata said,
as long as there remains an expecty-only jar, I'm not opposed to it
I have no strong feelings on the location of Expecty jar, as long as it being part of Verify doesn't get in the way of external users, like Weaver and folks that use Expecty with other frameworks.
How will we handle versioning? During different periods we were releasing Expecty fairly often, fixing the numerous bugs in Scala 3 implementation. I'd also like to keep tag-based releases, but afaik Verify is published differently.
Will it actually be possible to keep Expecty on separate release cadence?
How will we handle versioning? During different periods we were releasing Expecty fairly often, fixing the numerous bugs in Scala 3 implementation. I'd also like to keep tag-based releases, but afaik Verify is published differently.
If they are in the same code base, likely they'd be given the same version number, and we'll publish both more often. Yea. Verify is currently published manually by me, but I guess we'll do tag-based release.
Will it actually be possible to keep Expecty on separate release cadence?
I don't think we need to?