Thanks Buğra!
On Thu, Feb 20, 2025 at 2:22 AM Buğra Öztürk <ozturkbugr...@gmail.com> wrote: > Thanks for bringing this up Jarek! I like the idea of removing regexp > definitions from everywhere. > > First of all, for the CLI part, when we go remote, agree. We can make these > changes and include them as breaking since we will already make a bunch of > breaking changes there. For backward compatibility, it will vary between > local and remote. Local commands shouldn't be backward compatible and we > should document that. The remote will go to the API, and since the public > API will be backwards compatible, this should be backwards compatible, too. > Please correct me if I'm wrong. I would love to have no backwards > compatibility there to be more flexible. I am up for `Please use it Wisely` > documentation (should be one of the must-haves for local_commands) and most > likely update with glob in the next available iteration. > Yeah. Agree. It's good for now - but when we turn admin to "remote" we can change. I am not too worried about those > I think we also have in structure.py too where it is for UI. Again we have > root there used for task_ids_or_regex. Yep. Same story. I think this is the most "contentious" use and my question is - can we get rid of that regexp there. I don't know the full story on how "root" should be used there and whether other pattern matching can be used or maybe we should do something else - but I see that one (in multiple places as you noticed) as the only blocker from removing google-re2 as a dependency. > Maybe I am missing a use case here but the method is only used in the API > and old UI where it will be gone soon. I also found it used in the fast_api - but yes - maybe the new UI does not need the 'regexp' part there? I think there are few people who are way better equipped than me here :) - Brent, Pierre (others) ? Would love to hear some more about "root" usage. > I am not sure how easy would be to cover all cases of introducing regexp. > We may end up maintaining a step where it may miss lots of edge cases. I > don't have any strong opinion on this though, we may simply have checks and > that would help to increase awareness already. > That discussion alone might be a good protection for a while at least, but I am still trying to figure out some light-weight way to flag/ surface potential user-side regexp usage. But I am not too worried - so far the only one that is problematic is exactly the one we already knew about (via security report) - and It seems we did not have a temptation to use regex for other API calls. It also does not "feel" right to use regex in APIs. > -- > Bugra Ozturk >
