@tadejsv may u point to where jina tries to apply the regex, so that it may be easier for a community member to tackle this issue?

Yes, sure. One of the places it happens is for here

I would like to take on this issue but I'm unaware of the process here, should I ask to be assigned or I can directly submit a PR?

@Bharat123rox we assigned this to you. You can ask for any help

Right now, there does not seem to be a very good support for pathlib.Path objects in jina, for example

BaseExecutor.load_config(Path(__file__).parent / 'config.yml')

will throw an error (as jina tries to apply regex to Path). In (base) python, path strings and Path objects can be used interchangably, jina should follow this practice.

@tadejsv @JoanFM
Firstly, is there some sort of script/command I can come up with to search and find more (or possibly all?) occurrences or usages of Path objects?

I'm thinking of two possible approaches here to solve the problem:

1. (Preferred by me) Convert all Path objects to strings inside each occurrence / each Jina function, so regex and other functions truly intended for strings will work as-is and we will not need to refactor the functions other than adding something like:

s = str(s) if isinstance(s, pathlib.Path) else s

2. Continue to accept the path-like object as-is inside the Jina functions and refactor the base Python functions to their Path equivalent (For eg:- Path.match() for regex) but here in this case, it's likely that an equivalent Path function may not exist for some cases, so this may be better only for specific use-cases like a regex

Would you please be able to elaborate and let me know which approach would be better for this?

@Bharat123rox The proper approach is the second one, although it is harder. It might even be worth considering converting all string paths into Path objects, although I would not do this in this PR. Case in point: the regex used in the function I showed you is an overkill, all that needs to be checked is if the path ends in .yaml or .yml. Using Path this would be

return val.suffix in ['.yaml', '.yml']

Hey @tadejsv, in case we are going with the 2nd approach, then does that mean we are only going to fix methods where there are simple string regexes or specific use-cases where Path manipulations can be directly used? In other words, should we go through all functions accepting strings and try to refactor only those which can be replaced by a Path equivalent method like the above?

(P.S: I'm still working on this, it's been a hectic week and I hope to get a PR by this weekend!)