Fortran-lang.org package index#
The following criteria are required of packages to be indexed:
Relevance: the package must be primarily implemented in Fortran or provide a complete Fortran interface to an existing package or be purposed solely towards software development in Fortran.
Maturity: the primary functionality of the package shall be implemented. No prototype, testing or partially complete packages will be accepted. If the package is hosted on github or similar, it should have at least 5 ‘stars’.
Availability: the package source shall be freely available for browsing online or cloning or downloading
Open source: the package shall be licensed under an appropriate open-source license with the license file clearly included with the source code
Uniqueness: the package shall not be a fork or minor revision of existing packages
README: the package shall have some form of README or landing-page clearly stating the package purpose and functionality. This should also contain information on the package dependencies and the steps required to build and run.
The following criteria are not required but are recommended:
Documentation: any form of written documentation aimed at users of the package. Ideally this should cover:
Supported / tested compilers
Build and install process
Modules contained within the package
Procedures made available and their interfaces
Contributing: details on how users may submit issues and contribute to the development of the package
Tests: any form of executable test(s) that can be used to verify the functionality of the package
Portability: no non-standard language extensions or proprietary dependencies
FPM: support installation by the Fortran Package Manager fpm
Process for adding packages#
Users should confirm that their project meets the minimum requirements for listing in the Fortran-lang package index, as written in this document
Users should open a pull request using the ‘Package index request’ template
At least three Fortran-lang community members shall review the request against the criteria above
If three or more Fortran-lang community members agree that the package should be listed and there is no significant objection, then the pull request will be merged
Package index requests#
Package details are listed in the
data/package_index.yml data file.
To add a package simply create a new entry within this file. The data file is ordered by high-level categories merely to aid in navigation; find the appropriate category for your package and create a new entry.
After adding a new entry to package index, run the github action fortran_packages before building the sphinx build.#
Github hosted packages#
- name: <Package_name> github: <github_user>/<repository_name> description: <single_line_description> categories: <category1> [category2] tags: [tag1] [tag2] [tag3] version: [version] license: [license]
libraries: general libraries
interfaces: libraries that provide interfaces to other libraries, software or devices
programming: general programming utilities: errors, logging, testing, documentation etc.
data-types: libraries providing advanced data types: containers, datetime, resizable arrays etc.
strings: string handling libraries
io: libraries that parse and generate various file formats
graphics: plotting and GUIs
numerical: matrices, linear algebra, solvers, root-finding, interpolation, optimization, differential eqns, statistics, machine learning, random numbers etc.
scientific: domain-specific scientific libraries or applications
examples: repositories offering language feature demonstrations, tutorials and benchmarks
Projects listing more than one category must provide good justification thereof in the pull request.
The package description should clearly describe the functionality of the package in a single sentence.
Tags (optional) should contain any terms not already contained in the name or description that users may search directly for. Tags should be separate by spaces.
this can be determined automatically if a versioned release has been created on github
if version is specified, it will override any detected github version
if version is ‘none’, then no version information will be displayed. (Use this if your package has no version.)
this can be determined automatically if github is able to detect a known license
license must be specified if github is unable to detect a known license
Non-github hosted packages#
- name: <Package_name> url: <repo_url> description: <single_line_description> categories: <category1> [category2] tags: [tag1] [tag2] [tag3] version: [version] license: <license>
License and version information cannot be detected automatically for non-github repositories
if your package has no version, then omit the version field
a license must be specified for non-github repositories
Member review checklist#
Community members reviewing packages should cover the following points:
Ensure the package meets the minimum criteria as written in this document
Check the package metadata
Repository exists and is accessible
Description clearly and concisely describes the package
Assigned category is appropriate
Check license information
If license field has been omitted: check that github has detected the license
If license field is included: check that it matches repository license file
Check that package is available in expected category and search