-
-
Notifications
You must be signed in to change notification settings - Fork 651
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
Fix plugin location path decoding from Url #2190
Conversation
Hey @tarkah - thanks for looking into this! Could you please add some tests (even if just unit tests for the changed functions) to clarify what's going on here? Barring that (if it's too complex to add a test suite here) maybe add very detailed comments with examples? |
a3ce7a1
to
e182597
Compare
No problem! I did a bit more digging and there is definitely an issue w/ the
|
2b84868
to
93b7ce7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this, the test looks great!
* Add unit test for plugin run location parsing * Fix file plugin parsing for relative paths * Update test to check for path with spaces * Add a couple more tests
* Add unit test for plugin run location parsing * Fix file plugin parsing for relative paths * Update test to check for path with spaces * Add a couple more tests
Using URL file schema for plugin location is currently broken in a couple different ways:
PathBuf
doesn't decode the percent encoded URL. This makes any path with "spaces" or percent encoded characters break.path
or now w/to_file_path
always returns an "absolute"PathBuf
. The root prefix is now stripped when adding it to the config directory for relative lookup.I've tested both relative lookup
file:plugin.wasm
as well as absolute path w/ spaces and both now work.