The Funtoo Linux project has transitioned to "Hobby Mode" and this wiki is now read-only.
Difference between revisions of "Funtoo:Metatools/Releases/1.1.0"
Line 44: | Line 44: | ||
is demonstrated in the prometheus-bin autogen and works as follows. In an {{c|autogen.yaml}} you will have something like this for assets: | is demonstrated in the prometheus-bin autogen and works as follows. In an {{c|autogen.yaml}} you will have something like this for assets: | ||
<pre> | |||
prometheus: | prometheus: | ||
generator: github-1 | generator: github-1 | ||
Line 53: | Line 53: | ||
arm64: prometheus-{version}.linux-arm64.tar.gz | arm64: prometheus-{version}.linux-arm64.tar.gz | ||
template: prometheus-bin.tmpl | template: prometheus-bin.tmpl | ||
</pre> | |||
In the template, you will have something like this for {{c|SRC_URI}}: | In the template, you will have something like this for {{c|SRC_URI}}: | ||
<pre> | |||
SRC_URI=" | SRC_URI=" | ||
{%- for arch, artifact in artifacts.items() %} | {%- for arch, artifact in artifacts.items() %} | ||
{{ arch }}? ( {{ artifact.src_uri }} ) | {{ arch }}? ( {{ artifact.src_uri }} ) | ||
{%- endfor %}" | {%- endfor %}" | ||
</pre> | |||
==== YAML - Merged Defaults ==== | ==== YAML - Merged Defaults ==== | ||
Line 69: | Line 69: | ||
example, in the following example, the {{c|github/user}} would not get properly set, as the entire specific {{c|github}} section in the YAML for the {{c|foobar}} package would override the default value: | example, in the following example, the {{c|github/user}} would not get properly set, as the entire specific {{c|github}} section in the YAML for the {{c|foobar}} package would override the default value: | ||
<pre> | |||
my_autogen: | my_autogen: | ||
defaults: | defaults: | ||
Line 78: | Line 78: | ||
github: | github: | ||
repo: foobar_is_awesome | repo: foobar_is_awesome | ||
</pre> | |||
With the new implementation, any lists that exist both in defaults and in the specific package area will be appended to, and any dictionary/objects will have additional augmented attributes rather than overwriting the entire section. | With the new implementation, any lists that exist both in defaults and in the specific package area will be appended to, and any dictionary/objects will have additional augmented attributes rather than overwriting the entire section. | ||
Line 85: | Line 85: | ||
works with the "invisible defaults" that exist when specifying multiple package versions: | works with the "invisible defaults" that exist when specifying multiple package versions: | ||
<pre> | |||
my_autogen: | my_autogen: | ||
packages: | packages: | ||
Line 95: | Line 95: | ||
github: | github: | ||
repo: foobar_is_awesome | repo: foobar_is_awesome | ||
</pre> | |||
Above, {{c|github/user}} under {{c|packages/foobar}} sets defaults for all versions of packages under {{c|/packages/foobar/version}}, and previously, {{c|github/user}} would be overwritten whereas now both user and repo will be specified as arguments for the {{c|1.0.0}} version of {{c|foobar}}. | Above, {{c|github/user}} under {{c|packages/foobar}} sets defaults for all versions of packages under {{c|/packages/foobar/version}}, and previously, {{c|github/user}} would be overwritten whereas now both user and repo will be specified as arguments for the {{c|1.0.0}} version of {{c|foobar}}. | ||
Line 102: | Line 102: | ||
As described in {{Bug|FL-9856}}, it is now possible to specify multiple versions in {{c|autogen.yaml}} for any package. To do this, instead of specifying a "version: <version>" string | As described in {{Bug|FL-9856}}, it is now possible to specify multiple versions in {{c|autogen.yaml}} for any package. To do this, instead of specifying a "version: <version>" string | ||
to hard-code a version, or leaving it blank to imply "latest version", you can make {{c|version:}} an element with multiple version sections, each with their own version-specific settings if needed. For example, [https://code.funtoo.org/bitbucket/projects/CORE/repos/kit-fixups/browse/desktop-kit/curated/x11-terms/kitty/autogen.yaml here is the kitty autogen | to hard-code a version, or leaving it blank to imply "latest version", you can make {{c|version:}} an element with multiple version sections, each with their own version-specific settings if needed. For example, [https://code.funtoo.org/bitbucket/projects/CORE/repos/kit-fixups/browse/desktop-kit/curated/x11-terms/kitty/autogen.yaml here is the kitty autogen]: | ||
<pre> | |||
kitty_rule: | kitty_rule: | ||
generator: github-1 | generator: github-1 | ||
Line 118: | Line 117: | ||
0.25.1: | 0.25.1: | ||
python_compat: python3+ | python_compat: python3+ | ||
</pre> | |||
If you also want the latest version autogenned, use the special keyword "latest" for the version, which will result in the version being blank in {{c|pkginfo}} (indicating latest should be generated.) Metatools will turn each version specified into its own distinct autogen {{c|generate()}} call. | If you also want the latest version autogenned, use the special keyword "latest" for the version, which will result in the version being blank in {{c|pkginfo}} (indicating latest should be generated.) Metatools will turn each version specified into its own distinct autogen {{c|generate()}} call. |
Revision as of 21:17, August 19, 2022
Metatools 1.1.0 is a major release which was released on 19 August 2022.
ChangeLog
The 1.1.0 release of metatools has a number of significant updates:
- Major bug fixes in a lot of areas, including python-3.7 compatibility fixes.
- Massive improvements to error handling and ensuring you get a useful traceback when there is a problem.
- Major new features related to YAML autogens.
- Support for "closed loop fastpull" (better distfile handling for CDN).
- Useful new command-line arguments for tools.
- Major improvements to the github-1 generator and associated
github.py
metatools support code. - Dynamic archives support (powerful new feature)
Dynamic Archives Support
As described in FL-9270, it is now possible for an autogen to actually create its own tarballs which magically get added to the Funtoo CDN infrastructure with no additional steps on the autogen developer's part. Full documentation for this feature as well as a FAQ can be found here in the metatools repo: https://code.funtoo.org/bitbucket/users/drobbins/repos/funtoo-metatools/browse/docs/features/dynamic-archives.rst
New Command-Line Arguments
There are several useful, new command-line arguments.
Command-Line Arguments -- doit
- You can now use
--pkg
to specify the package name from the YAML you want to run autogen for. No other autogens will be run. - You can now use
--cat
to specify the category from the YAML you want to run autogen for. This can be combined with--pkg
. - You can now specify the specific
autogen.yaml
andautogen.py
files you want to auto-generate as positional arguments on the command-line. If no files are specified, the default behavior of recursively generating all autogens from the current path will occur. Otherwise, only those autogens specified will be executed. This can also be combined with the--pkg
and--cat
options.
Autogen YAML Improvements
There is significant new functionality related the YAML autogen syntax used in autogen.yaml
in a number of areas:
YAML - Multi-Arch Generators
As described in FL-9443, it is now easily possible to support GitHub projects that have arch-specific assets in their releases. This
is demonstrated in the prometheus-bin autogen and works as follows. In an autogen.yaml
you will have something like this for assets:
prometheus: generator: github-1 packages: - prometheus-bin: assets: amd64: prometheus-{version}.linux-amd64.tar.gz arm64: prometheus-{version}.linux-arm64.tar.gz template: prometheus-bin.tmpl
In the template, you will have something like this for SRC_URI
:
SRC_URI=" {%- for arch, artifact in artifacts.items() %} {{ arch }}? ( {{ artifact.src_uri }} ) {%- endfor %}"
YAML - Merged Defaults
Implemented FL-9664 to allow intelligent merging of defaults sections. Prior to this, subsections of YAML were not intelligently merged. For
example, in the following example, the github/user
would not get properly set, as the entire specific github
section in the YAML for the foobar
package would override the default value:
my_autogen: defaults: github: user: foobaroni packages: - foobar: github: repo: foobar_is_awesome
With the new implementation, any lists that exist both in defaults and in the specific package area will be appended to, and any dictionary/objects will have additional augmented attributes rather than overwriting the entire section.
This allows YAML to be cleanly extended and behaves intuitively. Defaults can be overridden but will generally not be discarded. This behavior also works with the "invisible defaults" that exist when specifying multiple package versions:
my_autogen: packages: - foobar: github: user: foobaroni version: 1.0.0: github: repo: foobar_is_awesome
Above, github/user
under packages/foobar
sets defaults for all versions of packages under /packages/foobar/version
, and previously, github/user
would be overwritten whereas now both user and repo will be specified as arguments for the 1.0.0
version of foobar
.
YAML - Multiple Versions
As described in FL-9856, it is now possible to specify multiple versions in autogen.yaml
for any package. To do this, instead of specifying a "version: <version>" string
to hard-code a version, or leaving it blank to imply "latest version", you can make version:
an element with multiple version sections, each with their own version-specific settings if needed. For example, here is the kitty autogen:
kitty_rule: generator: github-1 defaults: tarball: kitty-{version}.tar.xz github: user: kovidgoyal repo: kitty query: releases revision: 0.25.0: 1 version: 0.25.1: python_compat: python3+
If you also want the latest version autogenned, use the special keyword "latest" for the version, which will result in the version being blank in pkginfo
(indicating latest should be generated.) Metatools will turn each version specified into its own distinct autogen generate()
call.
New GitHub Features
The work on our GitHub API has been very significant and deserves its own documentation. This will be part of a future metatools release which will cover the metatools GitHub API in detail.