fedmod provides tools for working with Fedora's modulemd metadata format that aren't related to actually building them (for build commands, see fedpkg and mbs-build).
Currently, this consists of:
fedmod rpm2module
: generates a draft modulemd file based on
the given RPM name (multiple RPM names can be given, but the resulting
draft module will lack any descriptive metadata in that case)fedmod fetch-metadata
: download the F27 package and module metadata needed
to generate draft module definitions (the metadata sets to use are not yet
configurable)fedmod
is not yet released as an RPM, but can already generate basic draft
modules from a local development checkout:
$ pipenv run fedmod fetch-metadata $ pipenv run fedmod rpm2module graphite-web
This will generate a draft modulemd
file called graphite-web.yaml
in the
current directory.
See the local development instructions below for info on setting up the
execution environment with pipenv
.
Note: while an initial release is available from
PyPI, the dependency on the system level
dnf
and solv
libraries means it can't be usefully installed with pipsi
(as attempting to import those dependencies will fail at runtime).
fedmod
aims to generate draft module definitions based on the same repository
level metadata that dnf module
uses to actually install and manage modules.
While this is the most appropriate approach for generating further modules once we actually have an initial Fedora Modular Server release available with multiple modules defined (since it will ensure that the module metadata used is accurate and up to date), it has some limitations while that initial release is still being assembled.
In the meantime, https://github.com/fedora-modularity/dependency-report-scripts
allows for new module definitions to be generated based on the expected
contents of the initial module set. While modulemd
files created that way
are still reasonable for now, they're expected to lose accuracy over time as
module maintainers focus on dist-git and the actual module build service, and
stop updating the now redundant metadata files in
https://github.com/modularity-modules.
For now, a decent approach is to run both modulemd generators, and then pick whichever one you think looks better as your starting point.
fedmod rpm2module [RPM NAMES]
creates a modulemd file from the
given package names and emits it on stdout
. The YAML metadata can be written
directly to a file instead by passing the `--output
(or -o
) option:
$ fedmod rpm2module -o graphite-web.yaml graphite-web
The following metadata is currently used as input to the draft module generation process:
Package dependency definitions are pulled from the regular Fedora 27
release and updates repositories, with the metadata being downloaded for
local use via the fedmod fetch-metadata
command
Installable module definitions are pulled from the modular Fedora Bikeshed
repository, with the metadata being downloaded for local use via the
fedmod fetch-metadata
command
The definition of Fedora's build-only bootstrap
module is retrieved
directly from the relevant
dist-git repository
Descriptive metadata is taken from the system running fedmod
. Due to this,
fedmod
currently only supports Fedora 26+. (This will be fixed to use
the same repository metadata as is used for package dependency resolution)
Module dependencies currently err on the side of making the generated modules smaller by permitting generated modules to depend on packages that aren't listed as part of the public API of other modules. This reflects the fact that those transitive dependencies are typically the reason for the lower level modules appearing in the dependency set in the first place, as well as the fact that true dependency isolation will start being enforced once modules begin including opaque container images, such that only the client libraries are installed into shared environments.
Other limitations in generated modulemd
files:
components
are only given a name and rationale, relying on the default
settings for everything elsef27
.
This isn't right, but we can't set anything better until the mechanism for
depending on multiple streams without naming them specifically is defined.The preferred dependency management tool for development is pipenv
:
$ pipenv --three --site-packages $ PIP_IGNORE_INSTALLED=1 pipenv install --dev
The PIP_IGNORE_INSTALLED=1
setting means that everything available to pip
will be installed into the virtual environment based on Pipfile.lock
, and only
components that aren't installable with pip
will be used from the system
Python installation.
Some dependencies aren't currently available from PyPI, and hence need to be installed system-wide:
$ sudo dnf install python3-dnf python3-solv
pipenv
itself isn't packaged for Fedora yet, so the recommended bootstrapping
approach is to use the "pip script installer", pipsi
:
$ sudo dnf install pipsi $ pipsi install pew $ pipsi install pipenv
This will create a pair of isolated virtual environments in your home directory
specifically for pipenv
and the tool it uses for virtual environment
management, pew
. These can later be updated to newer versions using pipsi
:
$ pipsi upgrade pew $ pipsi upgrade pipenv
(Note: the pipsi list
command will list all packages installed via pipsi
,
and the commands they provide)
After going through the environment setup steps above, start a shell that's
correctly configured to run the tests with fedmod
and all of its
dependencies available:
$ pipenv shell
The metadata needed by the module generator tests can then be installed with
fedmod
itself:
$ fedmod fetch-metadata
The tests can then be run in the launched subshell with:
$ pytest tests
To see the Python level dependencies graph:
$ pew toggleglobalsitepackages $ pipenv graph $ pew toggleglobalsitepackages
(If you don't turn off global site-packages access first, you'll get the dependency graph of all the installed system Python components as well)