UnboundLocalError when dynamically imported

[js-truework]

Describe the bug

The sly library that scim2-filter-parser relies on will no longer be updated and is currently pinned at ==0.4 in pyproject.toml. Unfortunately the sly library also behaves poorly when being dynamically imported (such as by celery in a django application, or by ddtrace-run from datadog).

I don't think the whole problem needs to be solved by scim2-filter-parser, but I wanted to raise an issue to understand whether or not the as-of-recently unmaintained sly library would/could be replaced in future versions of scim2-filter-parser.

Others may encounter this issue, which surfaces as local variable 'pattern' referenced before assignment in sly.lex.Lexer._build. This happens when including django_scim.views in your application, since one of the imports of django_scim.views is scim2_filter_parser.parser.SCIMParserError, which in turn imports from sly import Parser, which causes the __init__.py in sly to run, which does from .lex import *, which then causes class Lexer(metaclass=LexerMeta): to be evaluated.

Again, I don't necessarily think this whole bug chain is the responsibility of scim2-filter-parser, but the issue has to be opened somewhere and since sly is a direct dependency of this repo and is no longer going to be maintained, I figured it would be a good place to call attention to potential problems that result from it. I captured more details on the sly bug in ticket dabeaz/sly#106, but expect no release to be made to fix it as the project is explicitly no longer maintained.

[logston]

Thanks for bring this up @js-truework! However, at the moment I'm very busy and don't see myself having the time work on replacing sly. Also, I no longer work at 15Five and thus don't know what the urgency is for a change like this at 15Five, but without a business need there's even less of a motivating factor. Not to say that there isn't a need from the community!

As for this is import error, we might be able to find a fix by maneuvering around sly and not importing it in the way we do now. However, I'd like to see how dabeaz/sly#106 turns out and potentially use those results first. Either way though, it looks like we'll need to vender sly into this repo if we do not want to replace it.

Can you ping on this thread (or anyone else that has this issue) as you see developments on the sly bug? If we don't see a fix in the next few months, then I'll try to find time to vendor sly into this repo and make appropriate fixes.

[js-truework]

Absolutely, I'm keeping an eye on both threads and will be happy to provide any updates that are relevant.

Wish you the best of luck with wherever you've ended up, thanks for the work you've done on the django-scim project so far!