注意:

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"

From Funtoo
Jump to navigation Jump to search
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:


{{code|lang=yaml|body=
<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}}:


{{code|lang=yaml|body=
<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:


{{file|lang=yaml|body=
<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:


{{file|lang=yaml|body=
<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>
{{code|lang=yaml|body=
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+
        keywords: '*'
</pre>
      latest:
        python_compat: python3_9+
        keywords: next
  packages:
    - kitty
    - kitty-terminfo
    - kitty-shell-integration
}}


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)
   Important

Please note that metatools requires a version earlier than 0.23.0 of httpx. 0.23.0 introduced breaking changes to the httpx API. Please see FL-9887 and FL-9888.

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 and autogen.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.