Conan Repositories

Conan Repositories

Conan is a package manager for C/C++ projects with a client-server architecture. Conan allows encapsulation of C/C++ project dependencies, distribution, and consumption in other projects. This involves the complex challenges of transitive dependencies, versioning, and licensing.

Conan works across Linux, OSX, and Windows platforms.

Supported Features

Limited Support for Conan 1.x

Nexus Repository does not have a Conan 1.x implementation for group repositories, but it does support a Conan 1.x proxy and hosted repositories.

You cannot use a Conan 1.x CLI client with revisions disabled to interact with a Conan 2.0 repository.

To use a Conan 1.x CLI client with revisions enabled, you must configure a Conan 2.0 repository.

The Conan 2.x CLI client throws an error when using a Conan 1.0 proxy repository. Use a Conan 1.0 proxy repository with the Conan 1.x client

Support for Conan 2.0

Conan 2.0 brings major changes, especially in creating package IDs, making them more reliable. Recipes need updates, and there's a new command-line interface.

Nexus Repository includes support for Conan 2.0 proxy, group, and hosted repositories.

Conan 1.x uses a static package ID based on settings, options, and dependencies. This could lead to collisions and ambiguity, especially with complex dependency graphs.

Conan 2.0 introduces a dynamic package ID that considers the package's type and dependencies' types. This results in more accurate and meaningful IDs, improving build reproducibility and reducing conflicts.

Learn more on the Conan Migration Documentation.

Conan 2.0: Emphasizes a more declarative and streamlined recipe format. This improves readability and maintainability.

Conan 1.x has a different command set than 2.0. Conan 2.0 redesigned CLI has improved consistency and usability. Some commands were renamed or replaced, requiring updates to scripts and workflows.

The CLI command Conan inspect is experimental and subject to breaking changes

Learn more from the Conan Inspect documentation.

You must use separate repositories in Nexus for Conan 1.x and 2.0 packages to avoid conflicts and ensure proper indexing. If you're migrating from Conan 1.x to 2.0, plan for a phased approach, updating recipes and client configurations gradually.

Search Parameters Added in Version 3.74.0

Additional search parameter support was added to Conan Hosted repositories in Nexus Repository version 3.74.0. These parameters are extracted from the conaninfo.txt settings and are used when Searching for Components in the user interface and through the REST API.

Existing users need to run the “Repair - Rebuild repository search“ task before the new search fields are indexed for existing Conan Hosted repositories.

Conan Revisions

Conan revisions are a feature in the Conan dependency and package manager that allows users to make changes to artifacts while maintaining a single Conan reference.

The goal of revisions is to make packages immutable so that they are never overwritten. This allows for reproducible builds and dependencies. Lockfiles can capture the exact state of a dependency graph, including versions and revisions, and can be used to force the use of those versions and revisions, even if new ones are uploaded to the servers.

A unique ID (revision) is associated with each Conan recipe export. When a recipe is changed, a new recipe revision (RREV) is created.

A new package revision (PREV) is calculated for each new package created. The PREV is based on the hash of the package contents. Multiple package revisions can belong to a single recipe revision, but the same package ID can't have multiple revisions that belong to different recipe revisions.

  1. Requires Nexus Repository with PostgreSQL database

  2. Applies to Hosted Conan repositories

  3. Add the Conan Bearer Token Realm

  4. Enable revisions for Conan as in the Conan documentation

Proxy Conan Repository

Steps to set up a proxy repository to access a remote repository location.

  1. Create a proxy repository

  2. Minimal configuration steps are as follows:

  3. Define a name for the proxy

  4. Select the Conan version

The Conan version cannot be changed after creating the repository.

  1. Define a URL for remote storage
         https://center2.conan.io
         ```

4. Select a blob store for the repository

2. If you will use HTTPS protocol for Conan and your Nexus Repository is configured to use a self-signed certificate, add your certificate to the trusted list:

1. Add the certificate to `<user_home>/.conan/cacert.pem`

3. Enable the Conan Bearer Token Realm

1. Navigate to Settings → Security → Realms

2. Add the `Conan Bearer Token Realm`

## Hosted Conan Repository

Conan-hosted repositories require an H2 or PostgreSQL database. Conan-hosted repositories may be used for either Conan V1 or V2 so there is not a version selector as with the proxy configuration.

Complete the following steps to set up a Conan-hosted repository:

1. Create a new hosted Conan repository in Nexus Repository

2. Enable the Conan Bearer Token Realm

1. Navigate to Settings → Security → Realms

2. Add the `Conan Bearer Token Realm`

Below is an example of using a hosted Conan repository:

conan remote add conan-hosted $HOSTED_REPO_URL
conan remote login conan-hosted [repo user] -p [repo password]
conan new hello/0.1
conan create . hello/world
conan upload hello/0.1@hello/world -r=conan-hosted


## Browsing Conan Repositories and Searching Packages

You may browse Conan repositories in the user interface inspecting the components and assets and their details, as described in [Browsing Repositories and Repository Groups](https://help.sonatype.com/en/browsing-repositories.html "Browsing Repositories").

Searching for Conan packages may be performed in the user interface as well. Find packages in the repository manager, as described in [Searching for Components](https://help.sonatype.com/en/searching-for-components.html "Searching for Components").

## Conan Client

These instructions detail how to configure the Conan Client with Nexus Repository.

1. #### Delete the Default Remotes

Delete the default remotes to avoid bypassing the Conan repository and stop packages from installing directly from remote servers.

Use the following command where `<remote name>` is the remote's name:

conan remote remove 


Use the following to delete the default remote:

conan remote remove conan-center


2. #### Add a New Remote to the Nexus Repository

To add a new remote with a link to the Conan repository, use the following command:

conan remote add 


|     |     |
| --- | --- |
| #### remote name | the Conan repository name |
| #### remote URL | the Conan repository URL |

The following command adds a Conan proxy repository with the name `conan-proxy`. To allow insecure server connections when using SSL include the `insecure` flag to the request:

conan remote add conan-proxy http://localhost:8081/repository/conan-proxy/ --insecure


See the [Conan documentation](https://docs.conan.io/2/reference/commands/remote.html#conan-remote-add) to learn more.

3. #### Update the Remote to the Nexus Repository

The following command changes the remote configuration (changes the remote URL or enables/disables SSL):

conan remote update 


You can review a list of configured remotes by using the following command:

conan remote list


## Content Selectors for Conan

When configuring [content selectors](https://help.sonatype.com/en/content-selectors.html "Content Selectors") for a Conan repository, you need to use two paths in the definition.

/repository/conan-releases/v1/conans/////upload_url

/repository/conan-releases/conans/////conanmanifest.txt or /repository/conan-releases/conans/////conanfile.py


Example content selector for a Conan-hosted repository:

format == "conan" and (path =~ ".//.+///." or path =~ ".///.+//.")