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

Minor improv. on testing-plugin & public CompilationResult #53

Closed
wants to merge 13 commits into from

Conversation

i-walker
Copy link
Member

@i-walker i-walker commented Nov 1, 2019

In order for us to have HeavyTests in the ide, which verify that MetaSyntheticPackageFragementProvider does its job and all PsiElements result in with valid references to their typeclass, we need the outputdirectory in CompilationResult classesfiles. I renamed it for coherence. Concluding that the CompilationResult DT is public, but our interpreter is still internal and not discoverable for users.

I am open to Feedback, separating the compilation and the actual interpretation of that result seems also to be a good pattern.
Contrary, if we don't make CompilationResult public we can't establish HeavyTests in testing. As there is no way for us to generate the metadata in the editor.

@@ -49,7 +49,7 @@ class ComprehensionsTest {
listOf(addCompilerPlugins(compilerPlugin))
},
code = {
codeSnippet.source
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd keep it because of: avoiding the use of primitives types, better types and it's planned to have several sources.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

May you reiterate on what you mean with multiple sources?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean about different snippets.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that should be isomorphic to List<Source>. What am indicating here is that your not doing anything to your DataType which is domain-specific other than renaming String to Source

val actualStatus: CompilationStatus,
val log: String,
val actualGeneratedFilePath: Path,
val classesDirectory: File
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are different directories and we only use classes directory. I think outputDirectory could be confused with the outputDirectory of the testing library.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

where is the outputDirectory of the testing library. I couldnt find it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

line 33

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, you're saying that classesDirectory is the same as outputDirectory?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They are different. That's the reason why I chose classesDirectory...

@@ -10,11 +10,11 @@ import java.nio.file.Paths

private const val DEFAULT_FILENAME = "Example.kt"

internal data class CompilationResult(
data class CompilationResult(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of doing CompilationResult public, I'd think about the desired assertion. The purpose of this library is to provide a simple testing framework. If we publish the compilationResult, it seems this library doesn't make sense and we might use the kotlin compiler testing library directly.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not writing an assertion

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I need the testing-library with the wrappers we added in testing-library. For the IDE it's a utility.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please, could you give more details?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

About what specifically?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

About the use of the library in IDE...

@rachelcarmena
Copy link
Member

rachelcarmena commented Nov 1, 2019

@i-walker , despite of the comments, thanks for this pull request!! I think it could be useful to think about the code you'd like to be able to write. What's the desired assertion you would like to write? And then, we could think about how to change the library.

@rachelcarmena
Copy link
Member

Another idea, @i-walker: use directly kotlin compiler testing library and then we'll think about a way to move your need to this library. I hope it's useful for you 🙏

@i-walker
Copy link
Member Author

i-walker commented Nov 1, 2019

We can also focus on the more pressing issue, that other libraries won't be able to pull testing-library

{
  "errors" : [ {
    "status" : 409,
    "message" : "The repository 'oss-snapshot-local' rejected the resolution of an artifact 'oss-snapshot-local:com/github/arrow-kt/kotlin-compile-testing/1.3.0/kotlin-compile-testing-1.3.0.pom' due to conflict in the snapshot release handling policy."
  } ]
}

@i-walker
Copy link
Member Author

i-walker commented Nov 1, 2019

This is a blocker for us because we already tried workarounds and pulling the underlying library directory and copy-pasting the code from testing-plugin doesn't seem to be an elegant solution.

@rachelcarmena
Copy link
Member

We can also focus on the more pressing issue, that other libraries won't be able to pull testing-library

{
  "errors" : [ {
    "status" : 409,
    "message" : "The repository 'oss-snapshot-local' rejected the resolution of an artifact 'oss-snapshot-local:com/github/arrow-kt/kotlin-compile-testing/1.3.0/kotlin-compile-testing-1.3.0.pom' due to conflict in the snapshot release handling policy."
  } ]
}

Sorry, I don't understand this error. We are not deploying that library in oss.jfrog.org. We're using JitPack to get that dependency.

@i-walker
Copy link
Member Author

i-walker commented Nov 1, 2019

Ok. How can we add testing-plugin to the dependencies in idea-plugin?

# Conflicts:
#	testing-plugin/src/main/kotlin/arrow/meta/plugin/testing/CompilationAssertions.kt
#	testing-plugin/src/main/kotlin/arrow/meta/plugin/testing/CompilerTestDSL.kt
@rachelcarmena
Copy link
Member

Ok. How can we add testing-plugin to the dependencies in idea-plugin?

It's already included in compiler-plugin for compiling/executing tests:

  • testImplementation project(":testing-plugin")
  • testRuntimeOnly dependencies for compiler-plugin and the rest of the libraries which are necessary to compile snippets in tests
  • JitPack repository:
repositories {
    maven { url "https://jitpack.io" }
}

because testing-plugin is using the dependency of kotlin-compiler-testing which is only provided by JitPack right now.

cc: @jansorg

@i-walker
Copy link
Member Author

i-walker commented Nov 1, 2019

Closing this

@i-walker i-walker closed this Nov 1, 2019
@i-walker i-walker deleted the is-testing-plugin branch November 1, 2019 19:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants