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

pelican -lr not reloading on content changes in 4.10.2 on Windows 11 #3431

Closed
mauricef opened this issue Dec 1, 2024 · 17 comments · Fixed by #3441
Closed

pelican -lr not reloading on content changes in 4.10.2 on Windows 11 #3431

mauricef opened this issue Dec 1, 2024 · 17 comments · Fixed by #3441
Labels

Comments

@mauricef
Copy link

mauricef commented Dec 1, 2024

  • [ 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.

@mauricef mauricef added the bug label Dec 1, 2024
@justinmayer
Copy link
Member

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?

@MinchinWeb
Copy link
Contributor

Sure thing!

@mauricef , would you be able to run pip freeze and paste the contents (or a screenshot) as a comment here?

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...)

@mauricef
Copy link
Author

mauricef commented Dec 2, 2024

It looks like it's this change

If I override IGNORE_FILES in pelicanconf.py and set it back to

IGNORE_FILES": [".#*"]

Then the changes are detected

@justinmayer
Copy link
Member

Good to know. Do you have any idea why this change has that effect? In theory, it should only ignore invisible files and folders.

@mauricef
Copy link
Author

mauricef commented Dec 2, 2024

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

anyio==4.6.2.post1
blinker==1.9.0
docutils==0.21.2
feedgenerator==2.1.0
idna==3.10
Jinja2==3.1.4
Markdown==3.7
markdown-it-py==3.0.0
MarkupSafe==3.0.2
mdurl==0.1.2
ordered-set==4.1.0
pelican==4.10.2
Pygments==2.18.0
python-dateutil==2.9.0.post0
pytz==2024.2
rich==13.9.4
six==1.16.0
sniffio==1.3.1
tzdata==2024.2
Unidecode==1.3.8
watchfiles==1.0.0

@MinchinWeb
Copy link
Contributor

@mauricef Thanks! I'll need some more time to dig into it, but I'll post back here

@Jonakemon
Copy link

Jonakemon commented Dec 4, 2024

@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.

@scbarton
Copy link

@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.

@justinmayer
Copy link
Member

@projectgus: Any idea why your change in #3424 would cause the problem mentioned in this issue?

@projectgus
Copy link
Contributor

Ah, snap. Sorry! I have not verified, but I think this might happen when the settings PATH value has its default of os.curdir, which is often "." .

So the watcher is coming back with paths like ./some_file.md and this is matching the ignore pattern .* as the unix-style globs also match directory separators. 🤦

I guess the quick fix is to revert that commit, sorry I didn't see this coming (my Pelican config has PATH set to a directory name).

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.

@yashaslokesh
Copy link
Contributor

My PATH is set to 'content' and I still encounter this error; using the old value for IGNORE_FILES works for me.

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

@justinmayer
Copy link
Member

@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! 😊

yashaslokesh added a commit to yashaslokesh/pelican that referenced this issue Jan 2, 2025
…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.
@yashaslokesh
Copy link
Contributor

Related but separate issue: on generation of the site with the default value of IGNORE_FILES = ['.*'], my content files beginning with '.' were still processed. I can report another issue and work on a fix for that.

pcraciunoiu added a commit to pcraciunoiu/embrangler_pelican that referenced this issue Jan 5, 2025
@pcraciunoiu
Copy link

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 IGNORE_FILES = [".#*"] fixes the issue.

yashaslokesh added a commit to yashaslokesh/pelican that referenced this issue Jan 14, 2025
…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.
@justinmayer
Copy link
Member

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! 😊

@verga
Copy link

verga commented Jan 14, 2025

I had the same problem on Linux (opensuse Tumbleweed) with version 4.10.2; adding the definition

IGNORE_FILES = [".#*"]

to pelicanconf.py solved the reload problem.

@justinmayer
Copy link
Member

I just released Pelican 4.11.0, which contains a fix for this issue. Many thanks to @yashaslokesh for the resolution! ❤️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants