Virtual envs are an implementation detail in Scala build tools

Author: mariogalic

_overviews/scala3-book/scala-for-python-devs.md

@@ -1293,7 +1293,7 @@ Follow the links below for more details:
 
 ## How to setup a virtual environnement in Scala?
 
-In Python there is a common practice of creating an isolated environnement for a particular project. For example, say we are working on application `myapp`, then using `venv` Python module we might do
+By default Python and Python modules are installed at system-wide directories or user-wide directories. Virtual environments are a way of obtaining an isolated environment on a per-project basis. Typical flow to configure the virtual environment using for example `venv` module in Python might be something like so
 
 ```
 cd myapp
@@ -1302,24 +1302,17 @@ source myapp-env/bin/activate
 pip install -r requirements.txt
 ```
 
-This installs all the dependencies under project's directory `myapp/myapp-env` and alters the shell environmental variable `PATH` to look up dependencies from `myapp-env`. Another popular approach is to use Pipenv
+This installs all the dependencies under project's directory `myapp/myapp-env` and alters the shell environmental variable `PATH` to look up dependencies from `myapp-env`.
 
-```
-cd myapp
-pipenv shell
-pipenv install
-```
-
-which makes use of `Pipfile` and corresponding lock file to manage dependencies.
-
-Key difference in Scala is that project's dependencies are not installed per project, and hence potentially same dependency of the same version is duplicated across multiple projects, but instead dependencies are installed inside a central local repository which is reused across projects. Dependency of particular version is installed only once and then reused across different projects that require it. For example using `sbt` build tool we specify dependencies inside `build.sbt` file (which is conceptually similar to `Pipfile`) under `libraryDependencies`, then executing
+In Scala there is no need to explicitly setup an equivalent of Python's virtual environnement. By default, build tools manage project's dependencies such that user does not have to explicitly think about site directories. For example using `sbt` build tool we specify dependencies inside `build.sbt` file under `libraryDependencies` setting, then executing
 
 ```
 cd myapp
 sbt compile
 ```
 
-downloads all the dependencies under the local repository. The location of the local repository can be queried with `show csrCacheDirectory` inside `sbt` shell. Note by using `sbt` each project gets its own isolated environment without the need for lock files or modification of the shell environnement. All the necessary paths are managed by the build tool itself. 
+would automatically resolve all dependencies for that particular project. The location of downloaded dependencies is largely an implementation detail of the build tool that users do not interact with directly. For example, if were to delete the whole sbt dependencies cache, one next compilation of the project, sbt will simply re-resolve automatically all the required dependencies.
+
 
 [collections-classes]: {% link _overviews/scala3-book/collections-classes.md %}
 [concurrency]: {% link _overviews/scala3-book/concurrency.md %}