Re: [gentoo-portage-dev] [Patch] Repoman rewrite stage2 modularization conversion complete

[Brian Dolbec]

On Mon, 14 Mar 2016 10:35:26 -0700
Brian Dolbec <dolsen@g.o> wrote:

> On Mon, 14 Mar 2016 10:14:15 -0700
> Zac Medico <zmedico@g.o> wrote:
>
> > On 03/05/2016 01:37 PM, Brian Dolbec wrote:
> >
 
> > Also, I see that the number of sys.exit calls in pym/repoman is up
> > from 37 to 41. I would prefer that we raise exceptions for the
> > caller to handle, rather than call sys.exit directly. I suppose we
> > change that later though, after we merge the code.
> > --
> > Thanks,
> > Zac
> >
>
> hmm, I don't recall adding any, that doesn't sound like me.  I did
> cringe a little every time I came across them.  I do agree that they
> need a better system. But I was concentrating on the modularization.
>
> Rather than wrapping the modules in try: except: pairs, perhaps we
> could add another variable to the dynamic_data similar to "continue",
> only an abandon-ship one, maybe "abort" to take them out of the
> modules.  Then the Scanner class could handle the exit in one
> consistent place.  Try/except can work nicely, but I've had to disable
> far too many to troubleshoot code from their misuse and being nested 5
> or more deep.
>

Ok, I just had a look through to see about changing those.  Many of
those "New" sys.exit calls are due to code duplication moving from
code blocks which handled multiple VCS types into the separate vcs
modules, and at least 4 of those are in docstring comments.

So, we should probably define an exception for those to raise.  And
hopefully find a nice central place to handle them correctly.

We can do that in master before we make the .29 release I think.

There are 3 in non-vcs code, 1 in the scan() in modules/scan/scan.py
and 2 in modules, one of which is an import failure exit for the
metadata.xml module.  The other is in the manifest module code which
looks like it could easily return {"continue": False, "abort": true}
and handle the case in the Scanner class.  That would also allow for
future modules to make use of an "abort" if needed.

As for the others, That is something we can work on in stage3 which was
intended for fixing up the remaining (crappy) code and optimizing...

-- 
Brian Dolbec <dolsen>