| Age | Commit message (Collapse) | Author |
|---|
|
This allows to simply specify the direct dependencies desired
to be absent at import where the dependency structure is handled
anyway, rather than afterwards reconstructing which repositories
should be absent.
|
|
When importing a repository via just-import-git, allow to
specify the value for the "inherit env" property for the
repository just being imported.
|
|
This allows to specify upfront alternative locations from where the
imported repository may be fetched. No action is taken in the
import, instead the argument gets passed intot he resulting just-mr
configuration.
|
|
|
|
In order to get the type checker happy, some wrong type annotations
were added and, as a consequence, an unwarrented conditional as well.
To make things worse, this as checking for the non-None-ness of a
value by inspecting the truth value, ignoring that the non-None value
"" also has truth value False. Remove this conditional alltogether
and fix the type annotations.
|
|
For maximum compatibility, we use the uppercase types from the
typing package instead of the built-in types, therefore compliant
with PEP 484 and PEP 526.
As unfortunately there is no proper JSON typing option that
requires many casts, we use a more lax typing for JSON inputs, but
enforce return types in order to implicitly infer the actual
format of an input JSON variable (dict, list, string etc.).
|
|
In the definition of a repository, the workspace root (given by
the key "repository") can contain either a description of that
root (where to fetch it, whast to expect) or simply a reference
to (the workspace root of) another repository. In the latter case,
the referenced repository has to be imported as a layer, just as if
had been specified as target_root, rule_root, or expression_root.
|
|
Add an option --plain pretending that the remote repository
configuration is the canonical single-repository one. In this way,
repositories not having a multi-repository configuration (e.g.,
code built with a foreign build system) can be imported in the same
way to a template, thus providing a more uniform interface. This
can also be useful, if a repository is to be imported completely
without its transitive dependencis.
|
|
... to allow simple chaining of imports.
|
|
|
|
The main repository to be imported should be treated special,
whenever given. This has to be verified as the parameter not being
None, rather than being true, as the empty string (a traditional
name for the main repository) is also a false value in python.
|
|
|
|
... assuming this repo already uses just and has a multi-repository
configuration committed. In the import, transitive dependencies, as
well as repositories serving as layers, are taken into account, and
"file" repositories are rewritten to be subdirs of the repository
imported. The imported repositories are renamed to reflect the
repository pulling them in, extending the name appropriately to
avoid conflicts. This renaming is reflected in the bindings and
layer references of the imported repositories as well.
In this simple version, no automatic deduplication of imported
repositories to already existing repositories is made, but the
user can specify that certain foreign repositories should not be
imported and mapped to already present repositories.
|
