home User Guide Getting Started Help Center Documentation Community Training Certification
menu
close
settings
Looker keyboard_arrow_down
language keyboard_arrow_down
English
Français
Deutsch
日本語
search
print
Importing Files from Other Projects

The Local Project Import feature is an experimental Labs feature that imports files from local LookML projects. Experimental features are not fully developed and may be significantly changed or completely removed.

Importing files from remote or local LookML projects is not currently compatible with model localization.

You can import files from other LookML projects and external repositories into your current project. This lets you use model files, view files, and other files in more than one project.

There are several use cases for this. A few examples:

To import files from another project, perform the following tasks:

  1. Create a project manifest file.
  2. Specify the local or remote projects that you want to import.
  3. View files from an imported project.
  4. Include files from an imported project.

You will then be able to reference fields from the imported project’s files and override the values of constants defined in the imported project, if the constants allow override.

Creating a Project Manifest File

Any project that imports files from other projects must have a project manifest file. If your project doesn’t already have a manifest file, you can create one.

To import projects, specify them in the manifest. You can specify local or remote projects, as described in the following sections.

Specifying Local Projects

Your Looker admin must enable the Local Project Import Labs feature in order to import local files into your project.

In a local import, the imported project must be present on the same Looker instance. Versioning is dynamic, meaning that changes in the imported project will immediately impact the project that imports it. This is a good option when the same team owns both projects and can validate changes in both places before pushing to production.

To import locally, use the project_name parameter to specify the current project. Use one or more local_dependency parameters to specify the project or projects to import:

# This project project_name: "my_project" # The project to import local_dependency: { project: "my_other_project" }

Specifying Remote Projects

In a remote import, the imported project does not need to be on the same instance. Rather, the project is imported through its remote Git repository.

To import a remote repository, use the remote_dependency parameter to provide the information for the remote repository. The remote_dependency parameter takes the following information and subparameters:

Here is an example remote_dependency parameter in a project manifest file:

remote_dependency: ga_360_block { url: "git://github.com/llooker/google_ga360.git" ref: "4be130a28f3776c2bf67a9acc637e65c11231bcc" override_constant: connection { value: "importing_project_connection" } }

Automatically Detecting New Versions of a Remote Project

You can have Looker automatically detect new commits in the remote project if you specify a Git branch or a Git release tag in the ref subparameter of remote_dependency in your manifest file.

For example, here is a remote dependency where the master branch is specified in the ref subparameter:

remote_dependency: exchange_rate { url: "https://github.com/llooker/datablocks-exchangerate.git" ref: "master" }

Subsequently, when the master branch is updated with new commits, Looker will automatically detect the changes.

And here is an example where the v1.0 release tag is specified:

remote_dependency: e_faa_original { url: "git://github.com/erin-docs/e_faa_folders.git" ref: "v1.0" }

Regardless of the type of ref you specify, even a commit SHA, the IDE will display the Update Dependencies button when you add a remote_dependency parameter to your project:

Click the button to bring in the remote project files. If this is the first remote dependency you’ve added to your project, updating dependencies will also prompt Looker to create a manifest lock file. Looker uses the manifest lock file to track the version of the remote project(s).

If you specify a Git branch or a Git release tag in the ref subparameter, Looker will check for new commits whenever the Looker IDE refreshes, which happens when a Looker developer goes into Development Mode, performs a Git action in the IDE, or refreshes the browser.

If there are new commits, Looker will display the Update Dependencies button in the IDE so you can bring in the latest remote project files. Once you have the latest files, you can validate your LookML to verify that all of your project’s references work with the updated remote project files. You can then fix any broken references and deploy your changes with no downtime for your users.

Manifest Lock File

Looker uses the manifest lock file to track the versions of remote imported projects:

Looker developers do not need to create or edit the manifest lock file, since lock files are managed automatically by Looker.

The manifest lock file shows each remote project, represented by a remote_dependency entry with url and ref subparameters:

Adding Authentication Credentials for Private Remote Repositories

The Project Settings page includes the Import Credentials tab, where you can manage authentication credentials for private remote repositories:

The Import Credentials tab lists the URL for each remote repository that has been defined in the project manifest file, the type of authentication used for the repository, and whether Looker can successfully connect to the repository.

To add authentication credentials for a repository:

  1. Hover over a repository name to display the Test and Edit buttons, and click Edit:

    Looker displays a dialog box letting you configure credentials for the remote repository. The dialog box will reflect the type of credentials required.

  2. If the repository requires a username and password for authentication, enter your username and password and click Submit:

  3. If the repository requires an SSH key, Looker displays a dialog box showing your local SSH key. Click Copy Key to copy the SSH key to your clipboard, and add it to your repository’s list of keys:

  4. After saving the credentials, click Test button to test Looker’s access to the repository:

    After successfully connecting to the repository, the Import Credentials page shows a green check mark next to the repository name:

Viewing Files from an Imported Project

For projects with IDE folders enabled, the Looker IDE displays imported project files in the imported_projects folder of the left navigation pane. You can click on an imported project file to view its contents:

Files from local projects and remote projects are listed in the imported_projects folder. All imported project files are shown in light gray to indicate that they are read only.

Since they cannot be edited, imported projects files are not visible when you are bulk-editing files in the IDE.

If your project has IDE folders enabled and your admin has enabled the Object Browser Labs feature, you can also view objects from imported project files in the object browser, which you can access from the left pane of the Looker IDE:

For more information on the object browser, see the Navigating Projects with the Object Browser documentation page.

Including Files from an Imported Project

The include parameter in a model file specifies the project files that will be available to that model. Once you specify a local or remote imported project in the manifest file, you can use the include parameter in a model file to specify files from the imported project. Only files whose project is listed in the manifest file can be included.

To include a file from another project, use the file name with two forward slashes (//) and the name of the imported project.

To include a file from another project, use the file name with two forward slashes (//) and the name of the imported project. If the imported project is enabled for IDE folders, follow the imported project name with a single forward slash (/) and the full path to the file you want to include.

For example, these include commands indicate the users view file from the e_flights imported project and the orders view from the e_commerce imported project:

include: "//e_flights/views/users.view.lkml" include: "//e_commerce/public/orders.view.lkml"

See the Path Syntax section for information on specifying paths with IDE folders enabled.

You can use wildcards to include multiple files. For example, to include all view files in the /views/ directory of the e_flights imported project:

include: "//e_flights/views/*.view"

Furthermore, you can use wildcards to scope to specific directory levels or to recursive directories in imported project:

include: "//e_flights/**/*.view.lkml" include: "//e_commerce/*/*.view.lkml"

See the Wildcard Examples section for information on using wildcards with IDE folders enabled.

Including Model Files

You cannot include a model file from another project. Instead, if you want to reuse, refine, or extend Explores across projects, in the imported project you can create a separate Explore file, then include that Explore file in other projects. See Including Explores in a Model for more information.

Including Files That Include Other Files

When you include a file that includes other files, all the includes are resolved before the file is passed on to the next project that includes it.

For example, if in your current project you import a file (A) from another project (proj_A) and the imported file contains an include parameter that includes file B from project proj_B, then file B will be included into file A before file A is imported into the current project.

Importing Data Files

Files stored in the Data section of a project are not imported. To reference a data file from an imported project, such as in the map_layer parameter, use the full path and file name of the file. For example:

map_layer: json_from_imported_project { file: "//path_to_imported_project/folder/filename.topojson" … }

Referencing Files from an Imported Project

After you have imported a view file into your project, you can use the syntax ${view_name.field_name} to reference the imported view’s fields as if the view file were native to that project. For example, say that you have imported the ga_360_block project in your project manifest file, and you have the following include statement in your model file:

include: "//ga_360_block/ga_block.view"

You would use the syntax ${ga_block.hits_total} to reference the hits_total field from the included ga_block view.

Passing Constants Between Projects

When importing files from one project into another, you can override the values of constants defined in the imported project’s manifest file. When you override a constant’s value, imported files that reference that constant will use the new value provided in the project that imports files.

The export subparameter of the constant parameter allows you to specify whether a constant’s value can, or must, be overridden in importing projects. The export parameter has the following possible values:

The local_dependency and remote_dependency parameters both have a subparameter, override_constant, which is used to override the value of a constant with export set to override_optional or override_required in the importing project.

As an example, let’s suppose that you are managing multiple databases on a single Looker instance, with a separate project for each database. In this example, let’s also assume that the data schemas are identical for each database, and that your goal is to define an analysis once and apply it to each dataset.

In this example, suppose proj_core is the base project in which you have defined views that you would like to import into other projects. In addition, one of the views that you would like to import is the orders view, which is defined as follows:

view: orders { sql_table_name: "@{schema_name}.orders" }

The schema that the orders view is based on is specified in the sql_table_name parameter using the schema_name constant, which is defined in the proj_core manifest file. In the example below, because the schema_name constant is set to export: override_required, any project that imports schema_name must override its value using the override_constant parameter:

constant: schema_name { value: "proj_core_schema" export: override_required }

For this example, let’s suppose that you would like to import the orders view into a local project called proj_a. There is also a table called orders in the database for proj_a with an identical structure to the orders table in the base project, proj_core.

Since proj_core and proj_a are on the same instance, you can import the orders view into proj_a using local_dependency. Using the override_constant subparameter of local_dependency, you can then update the schema_name constant to point to the schema proj_a_schema in the manifest file for proj_a:

project_name: "proj_a" local_dependency: { project: "proj_core" override_constant: schema_name { value: "proj_a_schema" } }

Overriding the schema_name constant in proj_a allows you to use the fields you defined in the orders view in proj_core, rather than creating a new view file and defining your fields from scratch. In this example, the orders view corresponds to a different table for each project:

Top