Github user ScrapCodes commented on a diff in the pull request:
https://github.com/apache/spark/pull/1179#discussion_r14115297
--- Diff: repl/src/main/scala/org/apache/spark/repl/SparkImports.scala ---
@@ -182,15 +182,26 @@ trait SparkImports {
// ambiguity errors will not be generated. Also, quote
// the name of the variable, so that we don't need to
// handle quoting keywords separately.
+ case x: ClassHandler =>
+ // I am trying to guess if the import is a defined class
+ // This is an ugly hack, I am not 100% sure of the consequences.
--- End diff --
This portion of code is just about importing, the ugly part is that there
should not be special casing for different things ideally. This can lead to
situations where we don't know what next needs a special case. Thus it is hard
for us to pitch this to change to original scala REPL.
The actual ugly part is next `case statement` where we put Val id =
something and then import it. This was the actual reason for this SPARK-1199
issue. But unfortunately we can not avoid it, because otherwise the remote
executors try to pull in classes which they don't need to. But since we are
living with that code for a while it should ideally be okay.
Yes importing without the intermediate val creation was the originally
followed style, which we changed to solve the problem described above.
Suppose we only used `code.append("import " + objName + ".INSTANCE" +
req.accessPath + ".`" + imv + "`\n")` this to import and no other way, then it
is much better than what we are doing and there will be no need for migration
of REPL for next upgrade.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
