Skip to content

Experiencing "Error: JSON schema not found at file://" #451

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

Closed
danielbachhuber opened this issue Oct 3, 2017 · 16 comments
Closed

Experiencing "Error: JSON schema not found at file://" #451

danielbachhuber opened this issue Oct 3, 2017 · 16 comments

Comments

@danielbachhuber
Copy link

When updating our dependencies from 5.2.1 to 5.2.2 today, we experienced this error:

Error: JSON schema not found at file://

Ref wp-cli/wp-cli#4393 and https://travis-ci.org/wp-cli/wp-cli/jobs/282809129

Let me know what situational details I can provide to help reproduce it. justinrainbow/json-schema is a dependency of Composer, which we use within our application.

@erayd
Copy link
Contributor

erayd commented Oct 3, 2017

Thanks for the heads-up. Could you please let me know the URI of the schema that's triggering the error, and how that schema is loaded? Also, does that schema contain an id, and / or any relative $ref?

@danielbachhuber
Copy link
Author

Could you please let me know the URI of the schema that's triggering the error, and how that schema is loaded? Also, does that schema contain an id, and / or any relative $ref?

I'm not entirely sure, but this looks like it could be it: https://github.com/composer/composer/blob/af519de0de087acb11450c2c10225377c8a909ff/res/composer-repository-schema.json

From https://github.com/composer/composer/search?utf8=%E2%9C%93&q=json-schema&type=

I also see https://github.com/composer/composer/blob/e12e0335a4d467878093fc76e3dea592ff3e1ce3/src/Composer/Json/JsonFile.php#L150

@erayd
Copy link
Contributor

erayd commented Oct 4, 2017

@danielbachhuber

I'm having difficulty reproducing this. I've done the following:

  1. clone wp-cli/wp-cli locally into /tmp/wp-cli
  2. Run composer install
  3. Update justinrainbow/json-schema to 5.2.2
  4. Inside /tmp/wp-cli, run ./bin/wp package install danielbachhuber/wp-cli-reset-post-date-command

Step 4 (i.e. the first failing travis test) seems to work perfectly without error, as do the other failing tests.

Are you able to provide a minimal test case, or instructions to reproduce?

@erayd
Copy link
Contributor

erayd commented Oct 4, 2017

steve@neith /tmp/wp-cli $ ./bin/wp package install danielbachhuber/wp-cli-reset-post-date-command
Installing package danielbachhuber/wp-cli-reset-post-date-command (dev-master)
Updating /home/steve/.wp-cli/packages/composer.json to require the package...
Using Composer to install the package...
---
Loading composer repositories with package information
Updating dependencies
Resolving dependencies through SAT
Dependency resolution completed in 0.001 seconds
Analyzed 441 packages to resolve dependencies
Analyzed 50 rules to resolve dependencies
Package operations: 1 install, 0 updates, 0 removals
Installs: danielbachhuber/wp-cli-reset-post-date-command:dev-master b8fee09
 - Installing danielbachhuber/wp-cli-reset-post-date-command (dev-master b8fee09)
Writing lock file
Generating autoload files
---
Success: Package installed.

@danielbachhuber
Copy link
Author

I've triggered a build to reproduce: wp-cli/wp-cli#4396

@danielbachhuber
Copy link
Author

I suspect I know what the issue is (now that I've managed to compare 5.2.1 and 5.2.2).

WP-CLI is built and distributed as a Phar archive. As such, prepending file:// to a path is erroneous because the file protocol inside a Phar is phar://.

I don't know enough about the json-schema codebase to offer an alternative at this point :/

@erayd
Copy link
Contributor

erayd commented Oct 4, 2017

@danielbachhuber It shouldn't be prepending file:// to anything unless there's no protocol provided at all. If phar:// is present in the base URI, then it will be left alone and relative URI will also be resolved as phar://.

I'll investigate to see if there's a possibility that something might be coming through from a phar archive that does not have a phar:// URI prefix on the base, as that would certainly trigger the issue.

@erayd
Copy link
Contributor

erayd commented Oct 5, 2017

I think it's caused by this. Nonsensical behavior, and apparently not a bug (although noting that phar archives are supposed to be filesystem-equivalent it sure seems like a bug to me). I'll refactor this code to avoid the use of realpath().

@erayd
Copy link
Contributor

erayd commented Oct 5, 2017

@danielbachhuber This is fixed in #455.

@danielbachhuber
Copy link
Author

👌 Thanks for your help with this, @erayd

@erayd
Copy link
Contributor

erayd commented Oct 5, 2017

No problem. Thanks for reporting the issue :-).

I'll update this issue once the fix is merged (@bighappyface needs to do that part). It'll go to 6.0.0-dev first, then backported for v5.2.5.

@erayd
Copy link
Contributor

erayd commented Oct 10, 2017

@danielbachhuber Now merged in 6.0.0-dev, and backported for 5.2.5 in #457.

@danielbachhuber
Copy link
Author

👍 Looking forward

@bighappyface
Copy link
Collaborator

@danielbachhuber
Copy link
Author

Created a build in wp-cli/wp-cli#4433

@danielbachhuber
Copy link
Author

5.2.5 fixes our issue. Thanks for your help @erayd @bighappyface :)

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

No branches or pull requests

3 participants