| @sylvass:albinvass.se | I know this has been brought up before, but I'm currently doing some work in zuul and I have a hard time understanding the data flow so while I'm working I'm adding type hints to let my language server help me a bit. So my question is if you'd be opposed to me adding type hints for the code I touch to make it easier for new contributors? | 09:20 |
|---|---|---|
| @sylvass:albinvass.se | * I know this has been brought up before, but I'm currently doing some work in zuul and I have a hard time understanding the data flow so while I'm working so I'm adding type hints to let my language server help me a bit. So my question is if you'd be opposed to me adding type hints for the code I touch to make it easier for new contributors? | 11:55 |
| @clarkb:matrix.org | > <@sylvass:albinvass.se> I know this has been brought up before, but I'm currently doing some work in zuul and I have a hard time understanding the data flow so while I'm working so I'm adding type hints to let my language server help me a bit. So my question is if you'd be opposed to me adding type hints for the code I touch to make it easier for new contributors? | 15:07 |
| corvus can probably explain better but it is my understanding that the type hinting experiment is being slowly unrolled as it created more problems than it helped solve. | ||
| I did look at Google's type checker which can do a lot of inference and also produce separate type files with the inference. The idea being if that works people could use that if they want type hints. But it only gets about 80% of the way there which isn't really enough to be useful because what it can't infer are voids that result in an inability to check entire files and then any file that also imports those files and you get a cascading inability to type check. | ||
| @sylvass:albinvass.se | Clark: I'm using pyright at the moment, but I'll take a look at how it compares to Googles pytype. In any case I didn't need to type hint everything to get a huge benefit since I was mostly using it to lookup object types and attributes, it isn't always obvious if a "connection" variable is a connection object or the connection name and so on. | 15:19 |
| @clarkb:matrix.org | sure you can get benefits in isolation for specific variables. The problem I was trying to solve was have the thing actually type check coherently as a whole | 15:22 |
| @sylvass:albinvass.se | I think I only put type hints in method/function arguments and on some object attributes that it wasn't able to infer | 15:22 |
| @clarkb:matrix.org | and do so without modifying the mode base (or modify it minimally) | 15:22 |
| @clarkb:matrix.org | and the end result is about 80% of files type check just fine (some of that is due to how the code is structured too) and the other 20% needs work to get enough info into the system thati nference works and type checking passes. I poked at it a bit and realized it wouldn't really be possible without changing course and I don't feel strongly enough to bother | 15:23 |
| @sylvass:albinvass.se | I suppose the issue is that the types could drift if they're not checked as part of a lint job | 15:24 |
| @clarkb:matrix.org | mostly was an experiment to see if it would make people happy who want the integration with an IDE | 15:24 |
| @clarkb:matrix.org | yes in my opinion there isn't any reason to have annotations if you aren't checking them | 15:24 |
| @clarkb:matrix.org | which is again why inference was potentially interesting. It just isn't there | 15:24 |
| @jim:acmegating.com | > <@sylvass:albinvass.se> I know this has been brought up before, but I'm currently doing some work in zuul and I have a hard time understanding the data flow so while I'm working so I'm adding type hints to let my language server help me a bit. So my question is if you'd be opposed to me adding type hints for the code I touch to make it easier for new contributors? | 16:24 |
| Please do not add type hints. They are being removed as we encounter them. Feel free to add docstrings. | ||
| @jkkadgar:matrix.org | If possible, I would like to have a discussion about https://review.opendev.org/c/zuul/zuul/+/915334 again. I got a solution that meets the needs of our developer workflow. Basically, in cherry-pick mode on Gerrit, the parent patchset of a change really doesn't matter for dependencies. What matters is knowing that a particular change is dependent and using the latest patchset as the parent. When a developer makes a relation chain of change A, B, and C, they will often just update B and then want to gate all the changes together. Without looking at the latest patchset, Zuul will assume that C can't gate because it's parent is an older patchset of B. I guess what I am wanting thoughts on is if this is an acceptable solution to this problem. I don't see any other way of solving this in Zuul without rearchitecting how changes are stored. | 19:55 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!