Julia Environments in Engee
The import and using statements differ in the context of the code and the files being downloaded, depending on the current environment. There are two types of environments in Julia:
-
Project environment (project environment) is a set of files and settings that define the environment for the development and execution of a particular project. The project environment includes settings and dependencies that are used in the project. In Julia, the project environment is defined using the Project.toml and Manifest.toml files, which contain information about dependencies and their versions:
-
Project file (Project.toml) is a file containing information about the direct dependencies of the project. It defines the names and identifiers (such as package names) that are used in the project. This file usually contains only direct dependencies and their versions.
-
Manifest file (Manifest.toml) is a file (if it exists) describing the complete graph (data structure) of project dependencies. Not only direct dependencies are included, but also all indirect dependencies that are used in the project. For each dependency, the exact versions (for example, packages) and other information necessary to ensure compatibility of the project source code with the versions of its dependencies are specified.
-
-
Project directory (project directory) is the place where the files and structure of your project are contained, including source code, settings, configuration files and package sets. The project environment is formed naturally from the structure of files and directories within the project directory. The directory contains packages and modules organized into a hierarchy of subdirectories. If there is a file
package name' inside the package directory.jlin the subdirectorysrc— this means that the packagepackage nameis available in this project, and its code is loaded through this file.
Thus, the project environment is the abstract environment in which the project dependencies are located, while the project directory is the place where the project files are physically stored. Read more in Uploading the code.
The Julia environment defines which packages and dependencies should be available for a particular project or application. Then LOAD_PATH in the form of a path array is used to tell Julia exactly where to look for packages and modules related to this environment:
-
LOAD_PATH[1] is the first element of the path array that specifies the path to the user environment files. The custom Manifest.toml and Project.toml files specify which packages and which versions are needed for this project. LOAD_PATH itself does not change either when adding packages (Pkg.add) or when changing the toml files of the environment. By default, the user environment is created using the path
/user/.project. This allows Julia to find and download the packages needed to execute the code in a given project. -
LOAD_PATH[2] is the second element of the path array that specifies the path to the system environment files. LOAD_PATH[2] specifies the path to system packages that are available for all projects and are independent of a particular project. The path to global toml files such as Manifest.toml and Project.toml is not included in the LOAD_PATH[2] element. Instead, the path to the directory containing these files is specified. Therefore, packages installed systemically can be accessed from any project, regardless of which packages are listed in its own project and manifest files. By default, the system environment is created using the path
/user/local/julia-1.M.N/environments/v1.M/, whereMandNare the version of Julia in the current project.
LOAD_PATH can contain not only two elements of the path array, but also any number of paths to the directories in which the packages are located. When Julia searches for a package to download using using or import, it checks all the paths specified in LOAD_PATH.
|
In addition to LOAD_PATH, there is also a subset of loaded_modules packages. loaded_modules (loaded modules) refer to the list of modules (or packages) that are currently active in the current Julia session. Each module is a set of functions and data that have been loaded and are ready for usage in the code.
Therefore, Julia can download and use the necessary packages from all environments, the paths to which are specified in the elements of the LOAD_PATH array. The 'Base.loaded_modules` function returns a list of loaded modules. For a better perception, the figure below is presented:
Julia can download and use the packages needed for the project using the paths specified in the elements of the LOAD_PATH[1] and LOAD_PATH[2] path arrays. Then the usage of using and import:
-
using' — use `usingif you need to load a module and make all its exported symbols available in the current namespace.usingloads a module into memory and adds it to the list of loaded modules (loaded_modules), which means that its functions and variables become available directly in the code. This is convenient when you need to use functions or variables from a module frequently without having to specify its name again. -
import— useimportif you need to load a module, but you don’t need to import all its characters into the current namespace.importdoes not load the module into memory and does not add it to loaded_modules, but creates a reference, allowing the use of symbols through qualified names. Useimportif you only need certain symbols from the module or need to explicitly specify their origin to avoid name conflicts.
So the main difference is that using loads and imports all the exported symbols of the module, while import creates a reference to the module, allowing you to choose which symbols to use.