I just didn't want to deal with any networking code in depchase. As I noted it was supposed to be temporary tool (same as I think fedmod is). In future we will not have traditional repositories so we don't need fedmod tool either.

Ideally we should use dnf for depsolving, but that is extremely slow and doesn't expose required stuff.

Note that you don't need mock at all. Dependency resolving will be same everywhere, be that inside chroot or outside.

It isn't mock itself that I want, it's compatibility with "koji mock-config". The idea is to use mock+dnf to handle the repo metadata download, and then fedmod can read it from there, rather than needing its own config system.

https://pagure.io/modularity/fedmod/c/bb9dd3009b5fcf1bbffe029fed59f354b8f643fb?branch=master adds the depchase code and removes the dependency on cached mbs-build metadata.

While the test suite still passes, I'm pretty sure the modulemd generation will be wrong, since the current tests don't cover whether or not dependencies on other modules are calculated and emitted correctly.

Next step will be to show that switching to depchase brings the test runtime down: the current tests take 20 minutes to run for me.

I realised that I was conflating two different things here - fedmod is currently hardcoded to use the F27 repo metadata, and merely switching to depchase doesn't require changing that.

So I've narrowed the scope of this issue to just be about which dependency resolution technique fedmod uses, and filed https://pagure.io/modularity/fedmod/issue/4 to cover making the metadata used configurable.

https://pagure.io/modularity/fedmod/pull-request/5 cut the runtime in half by dropping the ability to request module listings from PDC - we know from the discussion in https://pagure.io/fm-orchestrator/issue/717 that PDC isn't going to be the long term answer to that problem, and we'd already broken the current version of that capability in fedmod anyway when dropping the dependency on the mbs-build local tag cache.

I also tried an experiment with caching the DNF metadata reads, but that made no appreciable difference to the timing - time to break out a profiler and see where the time is actually going :)

@ncoghlan just replace dnf with depchase and you will get 100+x speedup ;)

@ignatenkobrain Aye, I assume that's going to be the real answer, but getting there means mapping from the way @dhodovsk was approaching the problem for modtools and the way you approached it for depchase.

Right now, I'm still working on the first half of that combination :)

@ncoghlan trying to improve code with wrong architecture is not right thing to do IMO.

@ignatenkobrain Indeed, but changing the architecture without first understanding the current arrangements isn't a good idea either.

OK, this is my last update using the current architecture: https://pagure.io/modularity/fedmod/pull-request/6

It gets the test runtime down to 150 seconds by caching DNF query results with functools.lru_cache, avoiding repeated lookups of the same packages.

I'm happy I understand the current setup well enough now to start deleting code and replacing it with the libsolv based approach from depchase next week :)

https://pagure.io/modularity/fedmod/pull-request/7 has been merged, which has the switch to depchase.

Test runtime is now around 20 seconds, rather than the original 20 minutes :)

@ncoghlan still slooooow!

@ignatenkobrain Aye, there are definitely still opportunities to make it even faster.

However, it's fast enough now to iterate on without too much hassle, which means I can switch to the "make it right" part of the "make it work, make it right, make it fast" cycle: https://pagure.io/modularity/fedmod/issue/9 :)

Thanks for the depchase code - figuring out the libsolv API from scratch would have been far more difficult than figuring out how to adapt depchase!