Scala: How can I install a batch system to work in repl?

In Python, if I install a package with pip install package_name , I can open Python repl by typing python and just import the package by its name, no matter what directory I am on the file system now.

In this way

 $ python Python 2.7.3 (default, Sep 26 2013, 20:03:06) [GCC 4.6.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import requests >>> 

and the requests library is imported, and I can play repl with it.

In Scala, I know how to do this in a project that uses sbt , but for training purposes, I would like to install the package so that I can just type scala on the command line and then import the installed package without being tied to a specific project.

 $ scala Welcome to Scala version 2.10.2 (Java HotSpot(TM) 64-Bit Server VM, Java 1.7.0_40). Type in expressions to have them evaluated. Type :help for more information. scala> import scalaz._ <console>:7: error: not found: value scalaz import scalaz._ 

How can i do this?

+6
source share
3 answers

Scala is different from Python. Code compiled for Scala 2.9.x is not compatible with 2.10.x. Thus, global definitions can cause many problems if you work with different versions.

You can use SBT and add to $ HOME / .sbt / plugins / build.sbt

 libraryDependencies += "org.scalaz" %% "scalaz-core" % "7.0.4" 

or

 libraryDependencies += "org.scalaz" % "scalaz-core_2.10" % "7.0.4" 

and then go to / tmp and run Scala REPL with SBT:

 sbt console 

But in the long run, this is not a good idea.

It would be best to install SBT, create a build.sbt file and put this in it:

 libraryDependencies += "org.scalaz" % "scalaz-core_2.10" % "7.0.4" scalaVersion := "2.10.2" initialCommands in console := "import scalaz._, Scalaz._" 

Now change the console to the build.sbt folder and run

 sbt console 

With this, you can experiment with REPL and import the story into the class path. In addition, it is easy to add additional dependencies. SBT is cool, you do not need to install new versions of Scala manually, just declare it in the build.sbt file.

+8
source

In addition to SRI, I use the following solution: shell script:

 /usr/bin/scalaz #!/bin/sh scala -cp ~/.ivy2/cache/org.scalaz/scalaz-core_2.10/bundles/scalaz-core_2.10-7.1.0-M3.jar ... other libs 

then just call it in terminal:

 $ scalaz Welcome to Scala version 2.10.3 (Java HotSpot(TM) 64-Bit Server VM, Java 1.7.0_40). Type in expressions to have them evaluated. Type :help for more information. scala> import scalaz._; import Scalaz._ import scalaz._ import Scalaz._ scala> Monad[Option].point(1) res0: Option[Int] = Some(1) scala> 
+1
source

This is usually not recommended, as most jar libraries are designed to be used with programmer projects. In addition, unlike other ecosystems, jar libraries are usually installed using some user-mode library management tool such as ivy or maven or sbt , as you may have noticed.

If you really want to do this, you can install the banks in the scala TOOL_CLASSPATH location, which you can find in the scala.bat or scala shell script file that comes with your scala distribution. In addition, you can create your own scala repl, which can load globally installed libraries from a specific configured location. In any case, it requires futzing with TOOL_CLASSPATH .

PS: I currently do not have access to the actual scala.bat file to help you with this, but you can find it here and here to understand what I mean. Please note that these files may not show how the .bat files are structured, as in the distribution (and can be quite dated). Please see it in the official distribution for information.

EDIT

I can explain a little more that I came back and looked at the actual scala batch and command scripts included in the official distribution :-)

As I said above, the scala script loads all the jar files present in the TOOL_CLASSPATH folder, which is usually ${SCALA_HOME}/lib . It also offers the option to add TOOL_CLASSPATH with the promising -toolcp option. See what it shows: (the batch version of the script is similar - I will just show things from the scala shell script).

 while [[ $# -gt 0 ]]; do case "$1" in -D*) # pass to scala as well: otherwise we lose it sometimes when we # need it, eg communicating with a server compiler. java_args=("${java_args[@]}" "$1") scala_args=("${scala_args[@]}" "$1") shift ;; -J*) # as with -D, pass to scala even though it will almost # never be used. java_args=("${java_args[@]}" "${1:2}") scala_args=("${scala_args[@]}" "$1") shift ;; -toolcp) TOOL_CLASSPATH="${TOOL_CLASSPATH}${SEP}${2}" shift 2 ;; -nobootcp) unset usebootcp shift ;; -usebootcp) usebootcp="true" shift ;; -debug) SCALA_RUNNER_DEBUG=1 shift ;; *) scala_args=("${scala_args[@]}" "$1") shift ;; esac done 

As you can see, this is very limiting - you need to specify each jar to be added. You can just use -cp ! Can we make it better? Of course, in this toolcp business we will have to extinguish.

 addtoToolCP() { for i in $(find $1 -name "*.jar") do if [[ -z "$TOOLCP" ]] then TOOLCP="$i" else TOOLCP="${TOOLCP}:$i" fi done } 

So, you can simply check the emptiness of our toolcp parameter and call scala accordingly as scala -toolcp $TOOLCP if it is not empty. Now you can just call your shell script like: myscalascript <list-of-paths-to-be-added-to-toolcp> . Or you can just save one folder and continue adding new libraries to this folder. Hope this helps, as others have said, to keep track of binary compatibility issues . Binary incompatibility issues will affect only major versions of scala, minor versions should be fully compatible. Finally, at the risk of repeating to death, use this only if you are sure you want this. :-)

0
source

Source: https://habr.com/ru/post/956227/


All Articles