-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
pelican -lr not reloading on content changes in 4.10.2 on Windows 11 #3431
Comments
I do not have access to any systems running Windows and thus cannot reproduce. I do not see much in the diff between 4.10.1 and 4.10.2 that would cause the described problem, but of course I cannot rule it out. @MinchinWeb: Could you run a few quick tests and see if you can confirm the problem described here? |
Sure thing! @mauricef , would you be able to run The drive you're watching, is it a local (i.e. attached to your computer) or network drive? Lastly, to confirm, you're remembering to save your (post) file after you change it? (I've been bitten by this an embarrassingly high number of times...) |
It looks like it's this change If I override IGNORE_FILES in pelicanconf.py and set it back to
Then the changes are detected |
Good to know. Do you have any idea why this change has that effect? In theory, it should only ignore invisible files and folders. |
I'm not sure, I'll play around with it some more, I see it gets translated to via fnmatch.translate and passed to watchfiles as a filter, I'll see if I can isolate the issue outside pelican. @MinchinWeb It's a local drive, I have confirmed I'm saving the file and here is pip freeze
|
@mauricef Thanks! I'll need some more time to dig into it, but I'll post back here |
@MinchinWeb running into the same issues on Ubuntu 22.04 with Pelican 4.10.2. The issue - I think - lies in 1edca55. It's the only meaningful commit between the two patch versions that could be the cause of the issue. |
@MinchinWeb I have the same problem on macOS 15.2 with Python 3.11.7 and Pelican 4.10.2. Reverting to 4.10.1 solves the problem. |
@projectgus: Any idea why your change in #3424 would cause the problem mentioned in this issue? |
Ah, snap. Sorry! I have not verified, but I think this might happen when the settings So the watcher is coming back with paths like I guess the quick fix is to revert that commit, sorry I didn't see this coming (my Pelican config has Although, it seems like the ignore patterns are being applied differently in the initial content search versus the auto-reload file watch, if the initial content search is working as expected. So the "best fix" long term is probably to make the file watch behaviour consistent to that. If this is still open in a week or two then I'll have a little time and would be happy to take a proper look at that, then. |
My I could take a look at this issue - maybe a small commit first to undo the ignore files setting change and then I can look into making the initial file search consistent with the autoreload file search |
@projectgus: Thank you for the thoughtful comment! Looking forward to having you involved in the resolution. @yashaslokesh: Many thanks for offering to take a closer look at this issue — that would be great. I would like to publish a release containing a fix in early January, so your assistance would be much appreciated! 😊 |
…h Unix shell wildcards The default `IGNORE_FILES` value of `'.*'` was being compiled to a regular expression and then passed into `watchfiles.DefaultFilter` to filter out files when autoreload is enabled. This commit compares the patterns from `IGNORE_FILES` directly with the filename to match the usage of `fnmatch` elsewhere in the codebase. The new filtering class will continue working as expected for custom `IGNORE_FILES` settings.
Related but separate issue: on generation of the site with the default value of |
I just ran into this issue as well, on Linux (Ubuntu), where autoreload doesn't work. I downgraded to 4.9 to and it worked again. I can confirm that setting |
…h Unix shell wildcards The default `IGNORE_FILES` value of `'.*'` was being compiled to a regular expression and then passed into `watchfiles.DefaultFilter` to filter out files when autoreload is enabled. This commit compares the patterns from `IGNORE_FILES` directly with the filename to match the usage of `fnmatch` elsewhere in the codebase. The new filtering class will continue working as expected for custom `IGNORE_FILES` settings.
For those subscribed to this issue, would you please take a look at the excellent work done by @yashaslokesh in PR #3441, confirm whether it addresses the problem for you, and submit a review on that PR with any relevant comments/feedback that you may have? Much appreciated! 😊 |
I had the same problem on Linux (opensuse Tumbleweed) with version 4.10.2; adding the definition
to |
I just released Pelican 4.11.0, which contains a fix for this issue. Many thanks to @yashaslokesh for the resolution! ❤️ |
[ x] I have read the Filing Issues and subsequent “How to Get Help” sections of the documentation.
[ x] I can reproduce this problem with stock/default settings file, theme, and sample content (as described in above “How to Get Help” sections of the documentation).
[ x] I have searched the issues (including closed ones) and believe that this is not a duplicate.
OS version and name: Windows 11 HOME
Python version: Python 3.12.4
Pelican version: 4.10.2
Link to theme: default
Links to plugins: default
Issue
I installed pelican 4.10.2[markdown] and ran the quickstart command and added a single article from the guide.
I run pelican -lr and editing the article does not cause an autoreload. If I downgrade to pelican 4.10.1, autoreload works as expected.
The text was updated successfully, but these errors were encountered: