Repository


Object Hierarchy:

Object hierarchy for Repository

Description:

[ CCode ( lower_case_csuffix = "irepository" , type_id = "g_irepository_get_type ()" ) ]
public class Repository : Object

`GIRepository` is used to manage repositories of namespaces.

Namespaces are represented on disk by type libraries (`.typelib` files).

The individual pieces of API within a type library are represented by subclasses of [class@GIRepository.BaseInfo]. These can be found using methods like [method@GIRepository.Repository.find_by_name] or [method@GIRepository.Repository.get_info].

You are responsible for ensuring that the lifetime of the [class@GIRepository.Repository] exceeds that of the lifetime of any of its [ class@GIRepository.BaseInfo]s. This cannot be guaranteed by using internal references within libgirepository as that would affect performance.

### Discovery of type libraries

`GIRepository` will typically look for a `girepository-1.0` directory under the library directory used when compiling gobject-introspection. On a standard Linux system this will end up being `/usr/lib/girepository-1.0`.

It is possible to control the search paths programmatically, using [method@GIRepository.Repository.prepend_search_path]. It is also possible to modify the search paths by using the `GI_TYPELIB_PATH` environment variable. The environment variable takes precedence over the default search path and the [method@GIRepository.Repository.prepend_search_path] calls.

### Namespace ordering

In situations where namespaces may be searched in order, or returned in a list, the namespaces will be returned in alphabetical order, with all fully loaded namespaces being returned before any lazily loaded ones (those loaded with `GI_REPOSITORY_LOAD_FLAG_LAZY`). This allows for deterministic and reproducible results.

Similarly, if a symbol (such as a `GType` or error domain) is being searched for in the set of loaded namespaces, the namespaces will be searched in that order. In particular, this means that a symbol which exists in two namespaces will always be returned from the alphabetically-higher namespace. This should only happen in the case of `Gio` and `GioUnix`/`GioWin32`, which all refer to the same `.so` file and expose overlapping sets of symbols. Symbols should always end up being resolved to `GioUnix` or `GioWin32` if they are platform dependent, rather than `Gio` itself.


Namespace: GI

Content:

Static methods:

Creation methods:

Methods:

Inherited Members: