On Fri, 11 Mar 2022 10:25:19 -0800 Alec Warner <anta...@gentoo.org> wrote:
> On Fri, Mar 11, 2022 at 9:14 AM Peter Stuge <pe...@stuge.se> wrote: > > > > Matt Turner wrote: > > > repoman is inferior to other tooling mentioned. The other tooling > > > is actually run in CI. > > > > The problem seems to be that CI is running something other than > > developers run, not the other way around. > > > > > > > Developers should get the same warnings locally as in CI. > > > > I agree. And developers and their tools should not have to bend to > > whatever CI does, I think the other way around makes more sense. > > > > > > CI doesn't use repoman because of performance issues. > > I think the problem is that making committers use the CI tool is > technically a fairly straightforward change; while everything you > discuss further in the thread is not; because it implies people will > work on improving tools that have shown little or no progress on > improving in the 15 years I've been in Gentoo. > Somewhat incorrect here. I did the majority of the re-write to make the code maintainable, extensible not that long ago. It even has the ability to be repository configurable and include the ability for custom repository plugin checks to be added and run. The CI system was being developed at the same time using pkgcheck. See my other reply to WilliamH for more detail about that and fundamental speed differences. > > > > What if pkgcore evolves to provide a portage-compatible API? > > No API is planned and no one is working on it. > I and a few others did some work to ensure pkgcore had some usable api's from early in it's development. But pkgcore is so different from portage code, it was difficult for early to mediocre python devs to wrap their head around. There was even work to make porthole be able to use pkgcore as it's backend package manager, but it was never fully utilized due to more work needed on pkgcore for some functionality. > > > > Then CI could use repoman without performance problems, and > > developers would also enjoy improved performance, without spending > > time on replacing tooling which already works for them. > No, pkgcore and it's QA tool pkgcheck are designed to work together. Repoman is designed to work with portage base code. Checks can be designed to work on either, but not both. The missing checks that the CI does can be added to repoman, but the primary dev(s) creating them on the CI don't recreate them for repoman. They want to work on pkgcheck. Repoman code will NEVER be as fast as pkgcheck due to the legacy portage code structure it relies on. Pkgcore was a re-design from the ground up to to improve upon the shortcomings of the original portage structure. This resulted in vast speed improvements and reduction in lines of code to do the same functionality. Portage (due to Zac) has made vast improvements in structure, but still requires a ton more changes to get to where it should be. > The benefit of getting people to change their behavior is that the > benefits (less breakage, better tooling) are achieved now; as opposed > to in some hypothetical future where repoman is improved. > Note that we have been waiting for 'improved repoman' for about 8 > years; so..I'm not willing to bet on it when we have better tooling > that works today and the primary complaint is that...what exactly? > > The new workflow with pkgcheck was announced at the end of 2019: > https://blogs.gentoo.org/mgorny/2019/12/12/a-better-ebuild-workflow-with-pure-git-and-pkgcheck > > It's been 2 years, I think we can bring everyone into the fold here. > > > > > Looking into the future then maybe portage could even come to use > > pkgcore for the low-level things that pkgcore does, then even users > > could enjoy improved performance. > > Many things could happen but again, if you talk to people who work on > pkgcore; there is no concrete plan for this. So I don't see why we are > betting on it happening. > > If you read radhermit's blog: > https://pkgcraft.github.io/posts/timesink-chronicles/ you can get one > take on the project and why it struggled. > > -A > > > > > > > Right? > > > > //Peter > > >
