User Guide Getting Started Help Center Documentation Community Training
New LookML
Old LookML
New LookML
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 projects from which 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.

Create 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.

Specify the Projects from Which You Want to Import

To import projects, specify them in the manifest. There are two methods of doing so: locally and remotely.

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. Versioning is static; changes in the imported project will not automatically reflect in the project that imports it. The desired version of the imported project is explicitly indicated. This is a good option for using Looker Blocks.

To import a remote repository, use the remote_dependency parameter to specify the URL of the Git repository and the commit SHA representing the version of the repository you want:

remote_dependency: ga_360_block { url: "git://" ref: "4be130a28f3776c2bf67a9acc637e65c11231bcc" }

To get the URL for a remote repository, copy its HTTPS URL and replace https:// with git://.

You can find commit SHAs anywhere you can browse the commit history. Git service providers usually makes the SHA clearly visible and copyable.

The name (in this example above, ga_360_block) can be anything you like. It will be used when you include its files in the following step.

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

New in Looker 7.0, files from imported projects are displayed in the left navigation pane of the IDE for projects with IDE folders enabled.

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.

Include 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 an 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, preface the file name with the other project name.

For example:

include: "//e-commerce/inventory_items.view" include: "//ga_360_block/ga_block.view"

You can use wildcards to include multiple files. For example, to include all view files in the IMPORTED_PROJECT project:

include: "//IMPORTED_PROJECT/*.view"

Although this syntax looks like a pathname, it doesn’t imply that files for the project are laid out in any particular way. You cannot use . or .. to specify relative paths as these are not paths — this is just how files are named in an include statement.

Including Model Files

You can include a model file from an imported project using the include parameter, just like a view file or other file type:

include: "//my_other_project/imported_model.model.lkml"

If you include a model file, and that model file defines a database connection using the connection parameter, that connection will override any database connection configured in the importing model file. See the include parameter documentation for more information on including model files in a different model file.

Including Files That Also Include Files

When including a file that includes other files, all the includes are resolved before being 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: