Log a warning when an executable is found, but does not have the exec…

[pmrv]

… bit set

[github-actions]

👈 Launch a binder notebook on branch pyiron/pyiron_snippets/warn

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
✅ +0.03% (target: -1.00%)	✅ 100.00%

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (7a4fe2a)	550	522	94.91%
Head commit (039f62f)	553 (+3)	525 (+3)	94.94% (+0.03%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#22)	3	3	100.00%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

---

_{🚀 Don’t miss a bit, follow what’s new on Codacy.}

_{Codacy stopped sending the deprecated coverage status on June 5th, 2024. Learn more}

[coveralls]

Pull Request Test Coverage Report for Build 10078911247

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 4 unchanged lines in 1 file lost coverage.
• Overall coverage increased (+0.06%) to 94.964%

---

Files with Coverage Reduction	New Missed Lines	%
resources.py	4	96.19%

Totals
Change from base Build 9941886607:	0.06%
Covered Lines:	528
Relevant Lines:	556

---

💛 - Coveralls

[pmrv]

Fixes #21.

[liamhuber]

I'm uncomfortable with the cross dependency to another part of the snippets package-- even if it is locked away and not top level.

I need to check, but if we import the logger and then just warnings.warn (or maybe (re)import the default python logger and pass a warning there) doesn't this get caught by the pyiron log? I thought it should bz virtue of the logger module configuring the base logger, but maybe I'm being naive about a fresh instance of the logger ignoring this

[pmrv]

I'm uncomfortable with the cross dependency to another part of the snippets package-- even if it is locked away and not top level.

I need to check, but if we import the logger and then just warnings.warn (or maybe (re)import the default python logger and pass a warning there) doesn't this get caught by the pyiron log? I thought it should bz virtue of the logger module configuring the base logger, but maybe I'm being naive about a fresh instance of the logger ignoring this

Fair, I think this should be possible, but will need to check.

[liamhuber]

Fair, I think this should be possible, but will need to check.

If it doesn't work pretty straightforwardly, I am content to make an exception (especially since it's not a top-level import), but let's check if we can have our cake and eat it too.

[pmrv]

The standard library has this, with the caveat that it redirects all warnings and to a hard coded logger, but it would be possible to setup similar logic in snippets.logger and redirect all warnings or warnings of a certain type to the pyiron logger. The warning type would have to be defined in a shared module somewhere so still link logger and resources.

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
✅ +0.05% (target: -1.00%)	✅ 100.00%

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (7a4fe2a)	550	522	94.91%
Head commit (efd976c)	556 (+6)	528 (+6)	94.96% (+0.05%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#22)	6	6	100.00%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

---

_{🚀 Don’t miss a bit, follow what’s new on Codacy.}

_{Codacy stopped sending the deprecated coverage status on June 5th, 2024. Learn more}

[jan-janssen]

Looks good to me

[liamhuber]

The standard library has this, with the caveat that it redirects all warnings and to a hard coded logger, but it would be possible to setup similar logic in snippets.logger and redirect all warnings or warnings of a certain type to the pyiron logger. The warning type would have to be defined in a shared module somewhere so still link logger and resources.

That's unfortunate. But now playing with it myself and thinking about it more, I really, really don't like invoking the snippets logger here. Anyone hitting this warning will suddenly get a pyiron.log file on their filesystem. This seems uncool for people importing a random (not-logger) class from pyiron_snippets.

An alternative would be something like sticking a ._logger = None attribute on the relevant class and then internally doing an if self._logger is None: warnings.warn(msg); else: self._logger.warning(msg), and manually setting the logger attribute when we're using the class where the pyiron logger is available? I feel this is still ugly, but less evil than writing surprise files for people.

[pmrv]

Agree about the uncleanliness when not using the logger otherwise, so I reverted back to warning. I've added a custom warning type, so that we could potential filter and redirect it to the logger in the future, but I'm not too married to it.