Julia Wednesdays at Engee

advanced users en

The import and using statements differ in code context and files loaded, depending on the current environment. There are two types of environments in Julia:

The *project environment (project environment) is a set of files and settings that defines the environment for developing and executing a particular project. The project environment includes the 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:
- The project file (Project.toml) is a file that contains information about the project’s direct dependencies. It defines the names and identifiers (such as package names) that are used in the project. This file usually contains only the direct dependencies and their versions.
- The Manifest file (Manifest.toml) is a file (if it exists) that describes the complete dependency graph (data structure) of the project. Not only direct dependencies are included, but also all indirect dependencies that are used in the project. For each dependency, the exact versions (e.g. packages) and other information necessary to ensure compatibility of the project source code with the versions of its dependencies are specified.
The project directory (project directory) is 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 the files and directories within the project directory. The directory contains packages and modules organised in a hierarchy of subdirectories. If there is a package name.jl file inside the package directory in the src subdirectory, it means that the package name package is available in this project, and its code is loaded through this file.

Thus, the project environment is the abstract environment where the project dependencies reside, while the project directory is where the project files are physically stored. Read more at Code Loading.

The Julia environment defines which packages and dependencies should be available for a particular project or application. LOAD_PATH as a path array is then used to tell Julia exactly where to look for packages and modules associated with that environment:

LOAD_PATH[1] is the first element of the path array, specifying the path to the custom environment files. The custom Manifest.toml and Project.toml files specify which packages and which versions are required for a given project. LOAD_PATH itself is not changed either when adding packages (Pkg.add) or when changing toml environment files. By default, the user environment is created at /user/.project. This allows Julia to find and load the packages needed to execute code in a given project.
LOAD_PATH[2] is the second element of the path array, specifying 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. Consequently, packages installed systematically can be accessed from any project, regardless of which packages are specified in its own project and manifest files. By default, the system environment is created at the path /user/local/julia-1.M.N/environments/v1.M/, where M and N are the version of Julia in the current project.

LOAD_PATH can contain not only two elements of the path array, but any number of paths to directories that hold packages. When Julia searches for a package to load using using or import, it checks all paths specified in LOAD_PATH.

In addition to LOAD_PATH, there is a subset of packages called loaded_modules. The 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.

Consequently, Julia can load and use the required packages from all environments whose paths are specified in the elements of the LOAD_PATH array. The Base.loaded_modules function returns a list of loaded modules. The figure below is presented for better understanding:

julia libs 1

Julia can download and use the packages needed for the project using the paths specified in the path array elements LOAD_PATH[1] and LOAD_PATH[2]. Then usage of using and import:

using - use using if you want to load a module and make all its exported symbols available in the current namespace. using loads the module into memory and adds it to the list of loaded_modules, which means that its functions and variables become available directly in code. This is useful when you need to frequently use functions or variables from a module without having to re-specify its name.
import - use import if you need to load a module but don’t need to import all its symbols into the current namespace. import does not load the module into memory or add it to loaded_modules, but creates a reference, allowing symbols to be used via qualified names. Use import if only certain characters from a module are needed, or if you want to explicitly specify their origin to avoid name conflicts.

Thus, the main difference is that using loads and imports all exported symbols from the module, while import creates a reference to the module, allowing you to choose which symbols to use.