feat: support relative paths

[lars-reimann]

Closes #76

Summary of Changes

The cwd of the worker process can now be set via the new data.cwd item of the program message.

[github-actions]

🦙 MegaLinter status: ✅ SUCCESS

Descriptor	Linter	Files	Fixed	Errors	Elapsed time
✅ PYTHON	black	5	0	0	0.88s
✅ PYTHON	mypy	5		0	2.65s
✅ PYTHON	ruff	5	0	0	0.04s
✅ REPOSITORY	git_diff	yes		no	0.01s

See detailed report in MegaLinter reports
Set VALIDATE_ALL_CODEBASE: true in mega-linter.yml to validate all sources, not only the diff

MegaLinter is graciously provided by

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (c32a4b6) to head (5dae678).

Additional details and impacted files

@@            Coverage Diff            @@
##              main       #83   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           11        11           
  Lines          522       530    +8     
=========================================
+ Hits           522       530    +8     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[WinPlay02]

The code is fine, just one conceptual question: How does this work with memoization?

Changing the cwd could lead to the same (relative) path resolving to different files.
As the timestamp is used to verify the valid re-usage of a file, this would probably not break correctness (and should be reasonably efficient, since the "older" files are not evicted from the cache (yet)), but it might cause confusion.

[lars-reimann]

The code is fine, just one conceptual question: How does this work with memoization?

Changing the cwd could lead to the same (relative) path resolving to different files. As the timestamp is used to verify the valid re-usage of a file, this would probably not break correctness (and should be reasonably efficient, since the "older" files are not evicted from the cache (yet)), but it might cause confusion.

Could file_mtime return a tuple containing the absolute path of the file and the mtime? The function would need to be renamed, though (e.g. file_id).

[WinPlay02]

Could file_mtime return a tuple containing the absolute path of the file and the mtime? The function would need to be renamed, though (e.g. file_id).

That should work, although reusing cached values between calls containing an absolute path and calls containing a relative path will not work.

[lars-reimann]

Another idea would be changing the code generator to create

safeds_runner.memoized_static_call("...", Table.from_csv_file, [safeds_runner.path('titanic.csv')], [safeds_runner.file_mtime('titanic.csv')]

instead of

safeds_runner.memoized_static_call("..", Table.from_csv_file, ['titanic.csv'], [safeds_runner.file_mtime('titanic.csv')]

[WinPlay02]

Another idea would be changing the code generator to create

safeds_runner.memoized_static_call("...", Table.from_csv_file, [safeds_runner.absolute_path('titanic.csv')], [safeds_runner.file_mtime('titanic.csv')]

instead of

safeds_runner.memoized_static_call("..", Table.from_csv_file, ['titanic.csv'], [safeds_runner.file_mtime('titanic.csv')]

The information about the parameters is available in the stubs via impurity information, so it could easily be added.
That would be the cleanest solution, as it shouldn't have any drawbacks.

[lars-reimann]

I'll do that after lunch.

[lars-reimann]

🎉 This PR is included in version 0.10.0 🎉

The release is available on:

• v0.10.0
• GitHub release

Your semantic-release bot 📦🚀