End-user should enjoy reading error messages around the `PATH` (mis-)declaration.

[x] I have read the Filing Issues and subsequent “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.

A couple of tiny corner cases of error conditions that I caught for settings.py while devising the expanded tests/test_settings.py Pytest unit test case file.

EDIT: (snipped two error cases as unrelated to load_source() and transferred them to issue #3369.)

Absolute outside subdirectory does not exist

Where PATH="/no-such-directory" is in /tmp/pelicanconf-invalid-PATH-1.py and that (absolute-type) outside /no-such-directory subdirectory does not exists.

$ python -m pelican -v -s /tmp/pelicanconf-invalid-PATH-1.py
[22:03:55] WARNING  WRITE_SELECTED is present in settings but    settings.py:563
                    this functionality was removed. It will have                
                    no effect.                                                  
           CRITICAL Exception: You need to specify a path        __init__.py:683
                    containing the content (see pelican --help                  
                    for more information)

An ERROR message should have said: /no-such-directory directory (as defined in PATH variable) does not exist.'

Inaccessible Directory

Where PATH="/tmp/pelican-unreadable-dir" in /tmp/pelicanconf-invalid-PATH-2.py and that /tmp/pelican-unreadable-dir subdirectory has no read access required for this user to enter that subdirectory:

$ python -m pelican -v -s /tmp/pelicanconf-invalid-PATH-2.py
[22:05:29] WARNING  WRITE_SELECTED is present in settings but    settings.py:563
                    this functionality was removed. It will have                
                    no effect.                                                  
           CRITICAL Exception: Could not find the theme          __init__.py:683
                    m.css/egbert-theme

An ERROR condition was missed and the program kept going along until it ran to an unrelated THEME error.

It should have said:

ERROR: File '/tmp/pelican-unreadable-dir' directory (as defined in 'PATH' variable) does not have read file permission bit access

User/Group Access Denied

When PATH=/home/user-who-is-not-me is used:

$ python -m pelican -v -s /tmp/pelicanconf-invalid-PATH-3.py 
[22:06:59] WARNING  WRITE_SELECTED is present in settings but    settings.py:563
                    this functionality was removed. It will have                
                    no effect.                                                  
           CRITICAL Exception: Could not find the theme

It did not error out.

An ERROR message should have said:

`/home/user-who-is-not-me' directory (as defined in 'PATH' variable) does not have directory ('x') file permission bit set.

Having the same error message for three(3) or 4 distinctive error conditions seems rather confusing to even the advanced end-user.

Platform

Click to expand

## Platform - **OS version and name**: Linux 6.1.0-21-amd64 SMP PREEMPT_DYNAMIC Debian 6.1.90-1 (2024-05-03) x86_64 GNU/Linux - **Python version**: 3.11.2 - **Pelican version**: HEAD (513abbf) - **Link to theme**: [m.css](https://github.com/egberts/m.css) - **Links to plugins**: [pelican-plugins](https://github.com/getpelican/pelican-plugins) - **Link to your site**: n/a - **Link to your source**: n/a

Two problems identified:

module_name must always be hard-coded to something like pelicanconf, regardless of path/filespec of its Pelican configuration settings file. Using this same module name ensures zero conflict with the built-in Python sys.modules while allowing Pelican end-user the freedom to specify any filename for its configuration settings file.
Careful cleanup for each unit test is now required to ensure that parallelized Pytest testing remain successful.

Note to myself: test_settings.py UT environment is somewhat incomplete: its UT of load_source()/settings.py is highly susceptible to contamination of prior configure_settings() UT without cleaning up to itself.

In short, configure_settings cannot be called repeatedly within a single unit test unless it is also a part of reload module unit test or having a suitable del sys.modules['default_conf'] (which is another whole ball of wax, of which, a Pelican config file named pathlib.conf could blow up due to that filename squashing one of its many "built-in" Python system module names, by using filename like site.conf, calendar.conf, rich.conf, platform.conf,

Module Name Analysis Still investigating the useability/viability of a seemingly more pleasant module name of pelican.conf which would be uniquely mapped from its -s <pelicanconf.conf> CLI argument. Only impediment to pelican.conf is when developer uses with XXXX from pelican.conf statement that actually does block our ability to "reload the configuration" (a feature set that is required for Pelican HTML server). If developer uses import pelican.conf statement, that is a much smaller impediment but causes a major rewrite of existing code so this avenue is not being pursued at all. Hence, the only minimally-rework but working prototype is the pelicanconf module name.

getpelican / pelican