When `self.wrap.filesdir` is a relative path, which happens when
`meson subprojects update` is run, the path to the patch must be
provided relative to the working directory in which `patch` or `git`
is run.
`self.wrap.filesdir` is absolute when `Resolve()` is invoked by the
Meson interpreter, which is why this wasn't detected by the tests.
We currently inconsistently handle connection, `has_ssl`, and printing
errors on urlopen failure between `meson subprojects` and `meson wrap`.
Make the latter work more like the former.
We have a fallback route in `meson subprojects download` and friends,
which tries to retrieve wrapdb urls via http, if Python was not built
with SSL support.
Stop doing this. Replace it with a command line option to specify that
insecure downloads are wanted, and reference it in the error message if
downloading fails due to SSL issues.
Using future annotations, type annotations become strings at runtime and
don't impact performance. This is not possible to do with T.cast though,
because it is a function argument instead of an annotation.
Quote the type argument everywhere in order to have the same effect as
future annotations. This also allows linters to better detect in some
cases that a given import is typing-only.
Do not traceback when trying to update a wrap that isn't a [wrap-file],
just report the problem.
Do not traceback on perfectly valid WrapDB wraps that don't have a
patch_url because they have upstream meson.build, instead try to parse
the version from the source tarball filename.
Use a derived type when passing `subproject` around, so that mypy knows
it's actually a SubProject, not a str. This means that passing anything
other than a handle to the interpreter state's subproject attribute
becomes a type violation, specifically when the order of the *four*
different str arguments is typoed.
This code path is only called on initial download of a subproject, but
if we raise an error and abort while downloading/applying a patch
overlay we still have the upstream sources extracted... which appears to
be a subproject, then turns out to be broken due to missing meson.build
Partially implements #9688
In some cases, init variables that accept None as a sentinel and
immediately overwrite with [], are migrated to dataclass field
factories. \o/
Note: dataclasses by default cannot provide eq methods, as they then
become unhashable. In the future we may wish to opt into declaring them
frozen, instead/additionally.
Since 0.59.0 Meson downloads multiple wraps in parallel, so the
packagecache directory could be created by one then the 2nd would hit
error when calling os.mkdir() because it already exists.
both of these do the same thing:
init -b <branchname>
-c init.defaultBranch=<branchname> init
The latter contributes to unreadably long lines of code, but has the
advantage of working on older versions of git.
Fixes#9449
Now, warnings are unconditionally raised when parsing the wrap file,
whether they are used or not. That being said, these warnings literally
just check for a couple of keys used in the .wrap ini file.
Moving these checks from the time of use to the time of loading, means
that we no longer report warnings only when originally downloading or
extracting the file or VCS repo.
It also means we no longer report warnings in one subproject, when a
wrap file is picked up from a different subproject because the first
subproject actually does a dependency lookup. This caused issues for the
WrapDB tooling, which uses patch_directory everywhere and the
superproject requires a suitable minimum version of meson for this...
but individual wraps might use a much lower version, and would then
raise a warning (in strict mode, converted to an error) when it resolved
a dependency from another WrapDB project.
Fixes#9118
There are two possible issues, both of which emit very long messages
from git:
- when shallow cloning via depth + a pinned commit we locally init
rather than cloning; use an almost-certainly not conflicting dummy
branch name
- any time a checkout of a revision is performed, it might not be a
branch name, in which case it will be a detached HEAD. By default git
is very noisy about this -- it wants you to know what happened and how
not to mess up. But wraps aren't per default intended for user editing
and development, it's just part of the internal transport which meson
uses. So, temporarily squelch this advice. Do not permanently
configure the repo like this though, because the user *might* cd in
and start developing on the subproject; in this case, any additional
git advice they trigger is their responsibility (and they probably do
want it).
Fixes#9318
"ERROR: Git program not found" is both highly true, and somewhat
inscrutable. Sure, looking at the line number you can basically figure
out that subproject('something') must somehow need git to operate, but
that may not be immediately obvious.
Make mention of the fact that it is needed to "download foo.wrap".
Fixes#7764
We have a lot of these. Some of them are harmless, if unidiomatic, such
as `if (condition)`, others are potentially dangerous `assert(...)`, as
`assert(condtion)` works as expected, but `assert(condition, message)`
will result in an assertion that never triggers, as what you're actually
asserting is `bool(tuple[2])`, which will always be true.
The dependency lookup is a lot of complex code. This refactor it all
into a single file/class outside of interpreter main class. This new
design allows adding more fallbacks candidates in the future (e.g. using
cc.find_library()) but does not yet add any extra API.
All changes were created by running
"pyupgrade --py3-only --keep-percent-format"
and committing the results. I have not touched string formatting for
now.
- use set literals
- simplify .format() parameter naming
- remove __future__
- remove default "r" mode for open()
- use OSError rather than compatibility aliases
- remove stray parentheses in function(generator) scopes
It doesn't make sense to check for the presence of git every time we use
it, but short-circuit any attempt to use a wrap right from the get-go
because we are trying to be fancy with submodules.
If git is not installed, simply do not try to figure out whether the
wrap is a submodule that can potentially be checked out/updated for the
user. Just take it on faith that it isn't one.
Fixes#2623
wraps from subprojects are now merged into the list of wraps from main
project, so they can be used to download dependencies of dependencies
instead of having to promote wraps manually. If multiple projects
provides the same wrap file, the first one to be configured wins.
This also fix usage of sub-subproject that don't have wrap files. We can
now configure B when its source tree is at
`subprojects/A/subprojects/B/`. This has the implication that we cannot
assume that subproject "foo" is at `self.subproject_dir / 'foo'` any
more.
Nirbheek Chauhan
Eli Schwartz
Paweł Marczewski
zxey
Will Toohey
Randy
Tristan Partin
Xavier Claessens
Daniel Jacobs
Dylan Baker
Daniel Mensinger
Dan
Seungha Yang
Jussi Pakkanen