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. ---