Jannis
02/22/2020, 12:01 PMarrow-test
.
• It being in its own repo means other repos will use a snapshot version of it. This means that the changes we are testing are not present in the compiled code of arrow-test
. As an example: I have a pr that changes the signature of a method in Applicative
in arrow-core
. In arrow-test
we have, in TraverseLaws
, a law which uses Id.applicative
and IO.applicative
which both come from the snapshot of arrow-core
. This means they don't have the changes and this leads to `AbstractMethodError`'s at runtime. This was partially solved by @Rachel with a short term workaround already by recompiling arrow-test
with a current version of the current repo before testing. For this pr this meant that the tests using Id.applicative
worked fine, but IO.applicative
still failed because it came from arrow-fx
and that is not being recompiled (it does not even have the required changes!). There are probably other compile issues similar to this, which are less discover-able and harder to debug.
• Any change in a core repo that changes a datatypes representation, it's equality instance or any method signature covered by laws has to first change arrow-test
otherwise it will never pass a test. This is a significant hindrance for changes as it leads to lots of fractured prs.
In my opinion the best way out of this is to split arrow-test
for each repo, such that arrow-core
has arrow-test-core
etc. Then force arrow-test-core
to only depend on local projects (or other arrow-test-*
). This would mean that changes to, for example, arrow-core
that would otherwise need to go to arrow-test
are now local. It still means we need to create follow up prs in the other repos, but solves the issues with the laws. Splitting this up is also a fast process which can be done incrementally: Create a new module per repo, copy all laws/generators and eq instances for this repo and last make all local tests depend on it. This technically should mean no test has to change (although some laws may have to change, like TraverseLaws
).
Unrelated to this I'd also propose to rename arrow-test
to something like arrow-laws
as it really only contains laws, generators and equality instances, not actual tests.
Thoughts/opinions/other ideas?pakoito
02/22/2020, 12:03 PMThoughts/opinions/other ideas?Back to monorepo 😄
Jannis
02/22/2020, 12:05 PMarrow-test
is a good idea even with a monorepo. It was always such a mess 😅raulraja
02/22/2020, 12:13 PMsimon.vergauwen
02/22/2020, 12:17 PMraulraja
02/22/2020, 12:31 PMJannis
02/22/2020, 12:34 PMraulraja
02/22/2020, 12:35 PMJannis
02/22/2020, 12:58 PMarrow-core
where we can discuss this approach further, because this really needs to be solved asap, because it will be blocking for some pull requests...arrow-core-data
for some reason has a dependency on all of arrow (through arrow-docs
which comes from arrow-ank
). This makes my initial plan of copying the source and just deleting/changing everything that fails to compile impossible for now, because you can actually do fx
and mtl
etc in `arrow-core`^^ I'll add the pr when this is fixed, already wrote rachel because I have no idea how that even happens 😅Rachel
02/24/2020, 9:31 AMarrow-test
and arrow-docs
are the two "hot" points. arrow-docs
should be re-organized as well. It was split and it doesn't contain the site. However, it still has source code that is used for code snippets from the apidocs and it can be split as well for every library.Rachel
02/25/2020, 1:58 AMarrow-test
and arrow-docs
. It will be improved during next days.Arkadii Ivanov
02/25/2020, 11:38 AMarrow-test
was archived. Aaaaaandd, my PR (https://github.com/arrow-kt/arrow-test/pull/10) was abandoned, again 😄 How should I proceed with the PR? It blocks my another PR (https://github.com/arrow-kt/arrow-fx/pull/33).aballano
02/25/2020, 11:39 AMRachel
02/25/2020, 11:40 AMsimon.vergauwen
02/25/2020, 12:05 PMArkadii Ivanov
02/25/2020, 12:11 PMarrow-fx
PR.Rachel
02/25/2020, 12:12 PMArkadii Ivanov
02/25/2020, 12:13 PM