distro_tracker.vendor

An app which enables Distro Tracker to access vendor-specific functionality.

Vendors can define their own specific set of rules for mail dispatch and the Web interface or provide additional data which Distro Tracker can plug in to appropriate functions.

Each rule should be implemented as a callable which takes a defined set of arguments with a predefined name. The supported callables are listed in the distro_tracker.vendor.skeleton.rules module of the distro_tracker.vendor.skeleton package which can serve as a starting point for the implementation of the vendor-specific functions.

Note

You should copy this package to a new directory and give it a descriptive name.

Note

Make sure the package is a valid Django app.

distro_tracker.vendor.call(name, *args, **kwargs)

Function which executes the vendor-specific function with the given name by passing it the given arguments.

It returns a tuple (result, implemented) where the values represent:

• result – the corresponding function’s return value. If the function was not found, None is given.

• implemented – a Boolean indicating whether the package implements the given function. This way clients can differentiate between functions with no return value and non-implemented functions.

Parameters

name – The name of the vendor-specific function that should be called.

Sample skeleton vendor

A skeleton of all vendor-specific function that can be implemented.

distro_tracker.vendor.skeleton.rules.classify_message(msg, package=None, keyword=None)

The function should analyze the message and decides which package is affected and the keyword to use when relaying the message to subscribers.

Parameters

• msg (email.message.Message) – The message to analyze

• package (str) – A suggested package. May be None.

• keyword (str) – A suggested keyword. May be None.

distro_tracker.vendor.skeleton.rules.add_new_headers(received_message, package_name, keyword, team)

The function should return a list of two-tuples (header_name, header_value) which are extra headers that should be added to package messages before they are forwarded to subscribers.

If no extra headers are wanted return an empty list or None

Parameters

• received_message (email.message.Message) – The original received package message

• package_name (str) – The name of the package for which the message was intended

• keyword (str) – The keyword with which the message is tagged.

• team (str) – The team slug for a message sent to the team or received through the team.

distro_tracker.vendor.skeleton.rules.approve_default_message(msg)

The function should return a Boolean indicating whether this message should be forwarded to subscribers which are subscribed to default keyword messages.

Parameters

msg (email.message.Message) – The original received package message

distro_tracker.vendor.skeleton.rules.get_pseudo_package_list()

The function should return a list of pseudo-packages (their names) which are to be considered valid pseudo-packages. Any existing pseudo-packages which are no longer found in this list will be “demoted” to subscription-only packages, instead of being deleted.

If there should be no update to the list, the function should return None.

distro_tracker.vendor.skeleton.rules.get_package_information_site_url(package_name, source_package=False, repository_name=None)

The function should return a URL to a package information Web page for the given package and repository. The repository parameter is optional.

If no URL exists for the given parameters, returns None.

Parameters

• package_name (string) – The name of the package for which the URL of the package information Web page should be given.

• source_package (Boolean) – If True the function should consider the given package a source package, otherwise it should be considered a binary package.

• repository_name – The name of the repository for which the package information should be provided.

distro_tracker.vendor.skeleton.rules.get_developer_information_url(developer_email)

The function should return a URL to extra information about a developer, by email address.

The function should return None if the vendor does not provide additional developer information or if it does not have the information for the particular developer email.

In this case, on the package page, a <mailto> link will be provided, instead of the additional information.

Note

This function can be used by other modules apart from the general panel

Parameters

developer_email (string) – The email of the developer for which a URL to a site with additional information should be given.

distro_tracker.vendor.skeleton.rules.get_external_version_information_urls(package_name)

The function should return a list of external Web resources which provide additional information about the versions of a package. Each element of the list should be a dictionary with the keys: - url - description

The function should return None if the vendor does not want to provide extra version information URLs.

Parameters

package_name (string) – The name of the package for which external version information URLs should be provided.

distro_tracker.vendor.skeleton.rules.get_maintainer_extra(developer_email, package_name=None)

The function should return a list of additional items that are to be included in the general panel next to the maintainer.

Each item needs to be a dictionary itself and can contain the following keys: - display - description - url

Note

Only the display key is mandatory.

The function should return None if the vendor does not wish to include any extra items.

Parameters

• developer_email – The email of the maintainer for which extra information is requested.

• package_name – The name of the package where the contributor is the maintainer and for which extra information should be provided. This parameter is included in case vendors want to provide different information based on the package page where the information will be displayed.

distro_tracker.vendor.skeleton.rules.get_uploader_extra(developer_email, package_name=None)

The function should return a list of additional items that are to be included in the general panel next to an uploader.

Each item needs to be a dictionary itself and can contain the following keys: - display - description - url

Note

Only the display key is mandatory.

The function should return None if the vendor does not wish to include any extra items.

Parameters

• developer_email – The email of the uploader for which extra information is requested.

• package_name – The name of the package where the contributor is an uploader and for which extra information should be provided. This parameter is included in case vendors want to provide different information based on the package page where the information will be displayed.

distro_tracker.vendor.skeleton.rules.allow_package(stanza)

The function provides a way for vendors to exclude some packages from being saved in the database.

Parameters

stanza (case-insensitive dict) – The raw package entry from a Sources file.

distro_tracker.vendor.skeleton.rules.get_extra_versions(package)

The function provides additional versions which should be displayed in the versions panel.

Each version to be displayed should be a dict with the following keys:

• version

• repository_shorthand

• version_link - optional

• repository_link - optional

The return value should be a list of such versions or None if the vendor does not wish to provide any additional versions.

Parameters

package (PackageName) – The package for which additional versions should be provided.

distro_tracker.vendor.skeleton.rules.get_table_fields(table)

The function provides additional fields which should be displayed in a table

One may add new specific BaseTableField to the fields defined in the table’s function default_fields. However, it is also possible to redefine the entire list of BaseTableField that must be displayed in the table.

The return value should be a list of such table fields or None if the vendor does not wish to provide any additional fields.

Parameters

table (BasePackageTable) – The table for which additional fields should be provided.

distro_tracker.vendor.skeleton.rules.additional_prefetch_related_lookups()

The function provides additional list of lookups to be prefetched along with the default lookups defined by BaseTableField classes.

The return value should be a list whose elements are either String or Prefetch objects

distro_tracker.vendor.skeleton.rules.get_vcs_data(package)

The function provides additional data which should be displayed in the VCS table field.

The return value should be a dictionary which will be merged with default context data defined by context function. If this function is defined then its return value is simply passed to the template and does not require any special format; the vendor’s template can access this value in the field.context context variable and can use it any way it wants.

Parameters

package (PackageName) – The package for which additional vcs data should be provided.

distro_tracker.vendor.skeleton.rules.get_bug_display_manager_class()

The function must return the class responsible for handling the dysplaying logic of bugs data. To this end, vendors must define a new class that either inherits from BugDisplayManager or implements the same interface defined by it.

distro_tracker.vendor.skeleton.rules.get_tables_for_team_page(team, limit)

The function must return a list of BasePackageTable objects to be displayed in the main page of teams.

Parameters

• team – The team for which the tables must be added.

• limit (int) – The number of packages to be displayed in the tables.

Existing vendors

• distro_tracker.vendor.debian
  • distro_tracker.vendor.debian.models
  • distro_tracker.vendor.debian.rules
  • distro_tracker.vendor.debian.tracker_package_tables
  • distro_tracker.vendor.debian.tracker_panels
  • distro_tracker.vendor.debian.tracker_tasks
  • distro_tracker.vendor.debian.tracker_urls
  • distro_tracker.vendor.debian.views
• distro_tracker.vendor.kali
  • distro_tracker.vendor.kali.rules