delta/buildstream.git/src, branch bschubert/fix-node-docs gitlab.com: buildstream/buildstream.git element.py: Fix documentation around `node` usage 2020-05-11T11:30:36+00:00 Benjamin Schubert contact@benschubert.me 2020-05-08T08:35:27+00:00 bc0d564f8a7a4b67e1cb8b5a49e9e9e0470da250 






downloadablefilesource.py: Make it publicly accessible
2020-05-09T09:32:42+00:00

Benjamin Schubert
contact@benschubert.me

2020-05-08T13:03:24+00:00

cae8cd14f5ad31687d578494cb707b353a241ac5

This is now part of the BuildStream public API and can be used to
implement new plugins





This is now part of the BuildStream public API and can be used to
implement new plugins







junction.py: Call node.validate_keys() in Plugin.configure()
2020-05-06T06:35:08+00:00

Tristan Van Berkom
tristan.vanberkom@codethink.co.uk

2020-05-05T09:18:53+00:00

03500289474cff921868d07732cd99ec12fb7dc9












_downloadablefilesource.py: Set user agent
2020-05-05T15:00:21+00:00

William Salmon
will.salmon@codethink.co.uk

2020-05-05T14:26:27+00:00

81e5ce707a919f2e0b4f8be5d8b1a44f2a5e355b

The default user-agnet for urllib is widely used for many bots and so is
blocked by many servers. Buy using our own then we we are not blocked by
gitlab.com etc and are also able to identify buildstream request to
servers.





The default user-agnet for urllib is widely used for many bots and so is
blocked by many servers. Buy using our own then we we are not blocked by
gitlab.com etc and are also able to identify buildstream request to
servers.







casdprocessmanager.py: Check if buildbox-casd process is alive while waiting for connection
2020-05-05T13:38:02+00:00

ctolentino8
ctolentino8@bloomberg.net

2020-04-09T14:28:39+00:00

7ca09c60f96d14cf6df219a9ebe5be31f688bb62












casdprocessmanager.py: Relax timeout for establishing buildbox-casd connection
2020-05-05T13:38:02+00:00

ctolentino8
ctolentino8@bloomberg.net

2020-04-09T14:25:40+00:00

a6eb85d1d47b9de930b3f3069bad702139b6a3f9












_pluginfactory/pluginfactory.py: Implement error reporting for pip origins
2020-05-04T11:16:38+00:00

Tristan Van Berkom
tristan.vanberkom@codethink.co.uk

2020-05-03T10:44:32+00:00

17259656bc2d9bbd001fa19170bb1f751ca272d1

For plugins loaded from the pip origin, we now support specifying constraints.

This is a non-breaking change and only involves specifying a package
with constraints when specifying the 'package-name', however there are
a few errors errors which can occur as a result, this patch tries to
handle them all cleanly and provide the user with useful error messages.





For plugins loaded from the pip origin, we now support specifying constraints.

This is a non-breaking change and only involves specifying a package
with constraints when specifying the 'package-name', however there are
a few errors errors which can occur as a result, this patch tries to
handle them all cleanly and provide the user with useful error messages.







_pluginfactory/pluginorigin.py: Store provenance of origins for error reporting
2020-05-04T11:16:38+00:00

Tristan Van Berkom
tristan.vanberkom@codethink.co.uk

2020-05-03T10:44:01+00:00

f17b84236391d27247aae9fb004c420b20b1142c












plugin.py: Rework how deprecation warnings are configured.
2020-05-04T08:55:32+00:00

Tristan Van Berkom
tristan.vanberkom@codethink.co.uk

2020-04-30T07:21:19+00:00

d1d002dec836579e0f708ad438a8265070963c51

This is mostly a semantic change which defines how deprecation warnings
are suppressed in a more consistent fashion, by declaring such suppressions
in the plugin origin declarations rather than on the generic element/source
configuration overrides section.

Other side effects of this commit are that the warnings have been enhanced
to include the provenance of whence the deprecated plugins have been used in
the project, and that the custom deprecation message is optional and will
appear in the message detail string rather than in the primary warning text,
which now simply indicates that the plugin being used is deprecated.

Documentation and test cases are updated.

This fixes #1291





This is mostly a semantic change which defines how deprecation warnings
are suppressed in a more consistent fashion, by declaring such suppressions
in the plugin origin declarations rather than on the generic element/source
configuration overrides section.

Other side effects of this commit are that the warnings have been enhanced
to include the provenance of whence the deprecated plugins have been used in
the project, and that the custom deprecation message is optional and will
appear in the message detail string rather than in the primary warning text,
which now simply indicates that the plugin being used is deprecated.

Documentation and test cases are updated.

This fixes #1291







_pluginfactory/pluginfactory.py: Add provenance to missing plugin errors
2020-05-03T02:52:26+00:00

Tristan Van Berkom
tristan.vanberkom@codethink.co.uk

2020-04-29T07:20:53+00:00

9084ae13d1872a21ae1a3298f44e192e7cf7ca8a

So far we were only reporting "No Source plugin registered for kind 'foo'",
without specifying what bst file with line and column information, this
commit fixes it.

Additionally, this patch stores the provenance on the MetaSource to
allow this to happen for sources.





So far we were only reporting "No Source plugin registered for kind 'foo'",
without specifying what bst file with line and column information, this
commit fixes it.

Additionally, this patch stores the provenance on the MetaSource to
allow this to happen for sources.