[
https://issues.apache.org/jira/browse/SYSTEMML-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Dusenberry updated SYSTEMML-1657:
--------------------------------------
Component/s: APIs
> Python package should force usage of associated JAR
> ---------------------------------------------------
>
> Key: SYSTEMML-1657
> URL: https://issues.apache.org/jira/browse/SYSTEMML-1657
> Project: SystemML
> Issue Type: Bug
> Components: APIs
> Reporter: Mike Dusenberry
>
> Currently, our Python package checks if a SystemML JAR is already present on
> the classpath, and if not, attempts to load the JAR that is shipped with the
> package. We should reverse this, and instead always try to use the
> associated JAR first, and if it is not available (such as during a local pip
> dev install without the JAR packaged), then look into the current classpath
> to see if the JAR is available. The reasoning is that in a hosted
> environment that has a version of SystemML preinstalled (i.e. the JAR is
> available on the classpath and the Python package is installed, with the idea
> of the underlying system being ready for either Python or Scala usage), if
> the user attempts to update the Python package via pip, the old JAR will
> still be on the classpath (since it is preinstalled), and thus the older JAR
> (i.e. 0.14) will be used by the newer Python package (i.e 1.0 dev), leading
> to issues. For extra clarity, we still want the Python package to fall back
> on a JAR on the classpath if a JAR is not part of the package, such as during
> local dev installs. We would just prefer that the Python package use the
> packaged JAR first.
> Here is the associated code:
> https://github.com/apache/incubator-systemml/blob/master/src/main/python/systemml/classloader.py#L64.
> Essentially, the try/catch block needs to be reversed, assuming we can for
> the JVM classloader to load the packaged JAR with priority to any existing
> SystemML JARs.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
