loader plumbings used by other loaders
Details
Wed, Feb 17
Tue, Feb 16
Build is green
Rework commit message (aligns with diff)
I wonder what would break if the new methods were just put in BaseLoader and the PackageLoader was made to inherit BaseLoader
Build is green
Adapt according to review:
- Drop swh.loader.pattern and move class Loader in swh.loader.core.loader module
- Drop unneeded self.create_authorities, self.create_fetchers
@ardumont points out that the base PackageLoader doesn't inherit from BaseLoader, which explains the new (common) base class. I think the new class could just as well be next to BaseLoader, and doesn't warrant the introduction of a pattern module.
@ardumont points out that the base PackageLoader doesn't inherit from BaseLoader, which explains the new (common) base class. I think the new class could just as well be next to BaseLoader, and doesn't warrant the introduction of a pattern module.
Are the new pattern module / pattern.Loader class really needed? It looks like these methods could live in the BaseLoader class directly.
This is great, thanks!
Build is green
Add missing test on cli run edge case
Build is green
Fix unused import
Build has FAILED
- Add missing test on Deposit.from_configfile
- Drop unneeded conditional in cli
Mon, Feb 15
Fri, Feb 12
Tue, Feb 9
Mon, Feb 8
Fri, Feb 5
Nov 20 2020
Nov 18 2020
Nov 3 2020
Oct 26 2020
Sep 25 2020
Our logging handler swh.core.logger.JournalHandler already knows how to pull some metadata from the celery tasks:
...
Build is green
Adapt according to suggestion