Debian control fields allow for alternative dependencies, which are
expressed by OR-ing them together with the '|' symbol. Support for this
is a bit complex. A tuple is used for the key instead of a simple
string, and the value is a dict of all the parsed data. (Callers will
need to be aware of the potential for keys to be tuples.)
This routine handles converting text strings consisting of
comma-delimited values into dictionary structures.
ppa-dev-tools will need to deal with several different forms of
comma-separated lists, including for command-line arguments (like
--architectures), Debian control file fields (like Build-Depends), and
migration issues (in the form <package>/<version>: <arch>, ...)
To provide flexibility in how the parser works, a couple optional
parameters allow overriding default behavior.
ppa: When no release is specified, default to supported releases
Previously we were assuming the devel release (i.e. lunar currently),
however if a PPA doesn't have builds for that release there will nothing
in the output except the headers. That looks wrong and doesn't really
fit user expectations.
Instead, make the default be all currently supported Ubuntu
releases (i.e. bionic, focal, jammy, kinetic, and lunar presently). The
display code already skips output for releases that the PPA doesn't
have builds for.
ppa: Force display of the result log URL if --show-urls given
For brevity we omit some of the details for passing results, however if
the user has specified the --show-urls argument explicitly, they
likely will expect to see log urls for both passing and failing results.
ppa: Set default to None for args with action store
argparse does not create Namespace attributes for arguments that the
user doesn't specify on the command line when configured with
action='store'. Explicitly setting default=None forces the attributes
to be included in the Namespace object, allowing the args to be checked
for presence.
I don't think this test case needs to test the team name or ppa address
since those are already adequately covered by test_ppa_group.py. This
test basically just needs to verify the specified command line arguments
were interpreted and applied correctly.
These options control whether packages can be uploaded to the PPA for
building. The option names and descriptions are drawn from Launchpad's
name and description of the same feature for consistency.
Expand support for setting CPU architectures for PPA
Options --all-architectures and --default-architectures (and abbreviated
forms for convenience) are added for the two most common use cases:
"Give me everything" and "Just the usual", respectively.
Note that ppa create's default behavior corresponds with
--all-architectures, NOT --default-architectures. 'default' here refers
to _Launchpad_'s default behavior, not ppa-dev-tool's. It's felt that
current users of this CLI tool prefer all architectures to be enabled.
However, it's likely there are people who are satisfied with Launchpad's
default, so --default-architectures is added as a straightforward to
understand way of setting things up that way. Note that since all
command line arguments can be specified in the config file, this gives
users an effective way to locally change this default behavior to their
own druthers.
create: Allow settings to be specified at creation time
Commit 3837ef8c states the intent for configuration settings to be
specified either at creation time or after. However that commit only
allowed the name and description. This commit modifies create() so it
can accept arbitrary settings, which are then passed directly to
Launchpad.
