Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

grass.app: Move mapset locking to library #4158

Open
wants to merge 10 commits into
base: main
Choose a base branch
from

Conversation

wenzeslaus
Copy link
Member

@wenzeslaus wenzeslaus commented Aug 8, 2024

This moves the lock_mapset function to the library. It introduces only small changes to the code, i.e., proper refactoring and deduplication in relation to the code elsewhere is still needed.

However, this unifies the error handling to always raising a custom exception. It also fixes the reported user using the mapset (before always the current user, now, the owner of the lock file; for that, lock file is removed only after getting its owner). It removes the debug message which I don't find particularly useful, for example it is currently misleading on windows and it is relatively easy to confirm the actual existence in process manager when debugging.

This moves the lock_mapset function to the library. It introduces only small changes to the code, i.e., proper refactoring and deduplication in relation to the code elsewhere is still needed.

However, this unifies the error handling to always raising a custom exception. It also fixes the reported user using the mapset (before always the current user, now, the owner of the lock file). It removes the debug message which I don't find particularly useful, for example it is currently misleading on windows and it is relatively easy to confirm the actual existence in process manager when debugging.

Committing with --no-verify due to textproto issue with pre-commit.
@github-actions github-actions bot added Python Related code is in Python libraries labels Aug 8, 2024
python/grass/app/data.py Outdated Show resolved Hide resolved
@wenzeslaus wenzeslaus marked this pull request as ready for review August 12, 2024 20:20
@wenzeslaus
Copy link
Member Author

This is now ready for review. Description updated accordingly.

@echoix
Copy link
Member

echoix commented Aug 13, 2024

What's the testing strategy you'd want here? For now, these code paths don't seem used by any pytest test, so we don't have code coverage to show that the new code is used (and the old one was too). I have Python code coverage working properly for gunittest on a PR in my fork, but it almost doubles the testing time, so I'm not pushing for it now (Ubuntu and macOS).
Would it make sense to take some time to create a special branch that would allow to collect complete code coverage for this PR, or you are confident enough that the current tests used the old code paths and now use all the new code paths?

@wenzeslaus
Copy link
Member Author

Basic tests are done by just running the grass command in the CI, but this is not covered and I did not add any new tests as it requires knowing the executable in the tests and we don't have that resolved. However, I did a lot of local testing and this is tested by any usage of GRASS GIS from CLI or with GUI, so I rely here on old-time user testing (people using main are a good group for this PR).

The situation is not ideal. There is at least one bug in the original code which I carried over. My hope is that with more refactoring this will be easier to fit and easier to test.

I welcome suggestions on getting the executable path or writing the tests for these in general, but it seems to me that in this phase, we need to let these PRs pass without much automated testing.

@echoix
Copy link
Member

echoix commented Aug 14, 2024

I welcome suggestions on getting the executable path or writing the tests for these in general, but it seems to me that in this phase, we need to let these PRs pass without much automated testing.

I'm fine with this approach, we need to incrementally do better and not stick too long for PRs that improves and makes the repo in better shape than without.

So what remains to review then is the actual Python. In my quick screening yesterday I didn't find anything that popped to my eyes. I invite another Python-only review.

@echoix
Copy link
Member

echoix commented Aug 14, 2024

Merging main to have it check on the pytest on macOS to see if the importing still works (it should, but if it fails there because of spawn it would have failed on windows too)

@echoix
Copy link
Member

echoix commented Aug 14, 2024

Merging main to have it check on the pytest on macOS to see if the importing still works (it should, but if it fails there because of spawn it would have failed on windows too)

It didn't fail :)

python/grass/app/data.py Outdated Show resolved Hide resolved
python/grass/app/data.py Outdated Show resolved Hide resolved
python/grass/app/data.py Show resolved Hide resolved
Comment on lines +226 to +228
msg = _(
"Unable to properly access '{}'.\nPlease notify your system administrator."
).format(lockfile)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Follow up from #4158 (comment)

Suggested change
msg = _(
"Unable to properly access '{}'.\nPlease notify your system administrator."
).format(lockfile)
msg = _(
"Unable to properly access '{lockfile_path}'.\nPlease notify your system administrator."
).format(lockfile_path=lockfile)

@veroandreo Does this make more sense than without it? I'm not completely sure, and it is the last element remaining for this PR to be unblocked.

(It might need to be reformatted, did it free-handed)

python/grass/app/data.py Show resolved Hide resolved
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
libraries Python Related code is in Python
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants