Couldn't create 'djangoql.parsetab'. Permission denied

[vkrizan]

The package version of djangoql (in Fedora) somehow gets this warning:

WARNING: Couldn't create 'djangoql.parsetab'. [Errno 13] Permission denied: '/usr/lib/python3.7/site-packages/djangoql/parsetab.py'

Do you know how or why this file is being created/modified?

The version is 0.13.0.

Thank you.

PS: I've opened a bug in Fedora (for myslelf) https://bugzilla.redhat.com/show_bug.cgi?id=1760757

[stebunovd]

it is created/modified by PLY, the library that is used internally for language parsing. This file is updated automatically if you're using a different version of the library than the one with which the file was created originally. However, even if it fails to update it, it should still be working.

Also, this bug dabeaz/ply#31 may be relevant.

[vkrizan]

I wonder if it would be possible to configure PLY to store it in different location, such as /var/lib.

[vkrizan]

So, I find the option to store it somewhere else, but is not very ideal.

To change the directory in which the parsetab.py file (and other output files) are written, use:

parser = yacc.yacc(tabmodule="foo",outputdir="somedirectory")

Note: Be aware that unless the directory specified is also on Python's path (sys.path), subsequent imports of the table file will fail. As a general rule, it's better to specify a destination using the tabmodule argument instead of directly specifying a directory using the outputdir argument.

I guess we have to ignore the warning and/or wait for the bug that you've mentioned to be fixed.

I'd can check how other packages/projects deal with ply when their modules are written system-wide.

[stebunovd]

yep, yacc() accepts tabmodule parameter, and DjangoQLParser() forwards **kwargs to yacc. However, on the end user level it is not configurable yet. Maybe we could add an optional configuration parameter for it in Django settings - do you think it would solve your use case?

[vkrizan]

I've noticed the kwargs, but I am not sure if it would help to solve the issue. The ply idea is to have the file Python-importable. So, if the application, that would use djangoql, also be packaged (in /usr/lib), then it would have the same warning issued.

I guess this is more of a problem on PLY side. I am thinking of a way for PLY to import the file without it being on python.sys.path. For example by reading and evaluating the file. That way it can be in any directory without meddling with python.sys.path.

I'll try to think up with something. Feel free to close this issue.

Thank you very much for your support.