pyre init fails for new project

[benzid-wael]

I am trying to setup pyre and I'm not able to initialize it
When I run pyre init, I got the following error:

ƛ Cannot locate a .pyre_configuration file in the current directory or any parent directories.

Steps

1. pip install pyre-check watchman
2. pyre init

Environment

• OS: MacOS Mojave
• Python: 3.7.8

[MaggieMoss]

@benzid-wael thanks for reporting - we are working on a fix and I will do another open source release once it merges.

[cooperlees]

It seems a Path() object also needs to be changed to a str. Is that bug known / fixed / planned to be fixed?

cooper-mbp1:ptr cooper$ /tmp/tp/bin/pyre init
 ƛ Also initialize a watchman configuration? [Y/n] Y
{
    "version": "20200818.230021",
    "watch": "/Users/cooper/repos/ptr",
    "watcher": "fsevents"
}
 ƛ Which directory should pyre be initialized in? (Default: `.`): .
Traceback (most recent call last):
  File "/tmp/tp/bin/pyre", line 10, in <module>
    sys.exit(main())
  File "/private/tmp/tp/lib/python3.7/site-packages/pyre_check/client/pyre.py", line 273, in main
    return arguments.command().run().exit_code()
  File "/private/tmp/tp/lib/python3.7/site-packages/pyre_check/client/commands/command.py", line 337, in run
    self._run()
  File "/private/tmp/tp/lib/python3.7/site-packages/pyre_check/client/commands/initialize.py", line 159, in _run
    json.dump(configuration, configuration_file, sort_keys=True, indent=2)
  File "/opt/homebrew/Cellar/python37/3.7.5_3/Frameworks/Python.framework/Versions/3.7/lib/python3.7/json/__init__.py", line 179, in dump
    for chunk in iterable:
  File "/opt/homebrew/Cellar/python37/3.7.5_3/Frameworks/Python.framework/Versions/3.7/lib/python3.7/json/encoder.py", line 431, in _iterencode
    yield from _iterencode_dict(o, _current_indent_level)
  File "/opt/homebrew/Cellar/python37/3.7.5_3/Frameworks/Python.framework/Versions/3.7/lib/python3.7/json/encoder.py", line 405, in _iterencode_dict
    yield from chunks
  File "/opt/homebrew/Cellar/python37/3.7.5_3/Frameworks/Python.framework/Versions/3.7/lib/python3.7/json/encoder.py", line 438, in _iterencode
    o = _default(o)
  File "/opt/homebrew/Cellar/python37/3.7.5_3/Frameworks/Python.framework/Versions/3.7/lib/python3.7/json/encoder.py", line 179, in default
    raise TypeError(f'Object of type {o.__class__.__name__} '
TypeError: Object of type PosixPath is not JSON serializable

[cooperlees]

The pyre config file are also not valid:

cooper-mbp1:ptr cooper$ cat .pyre_configuration
{
  "binary": "/tmp/tp/bin/pyre.bin",
  "source_directories": [
    "."
  ],
  "taint_models_path": "/private/tmp/tp/lib",
  "typeshed":

• Also, I spin up a new venv to use pyre and this changes every time, I don't feel there is any benefit to me having a config file ...

watchman (just empty):

{}

[TomMD]

Same as @benashman and @cooperlees, I'm experiencing that a recent release broke pyre entirely.

Situation Details

It used to be possible to call git clone $some_repo path ; cd path ; pyre --noninteractive --source-directory . --output json but now a pyre configuration is required. Perhaps that behavior was intentionally changed, but printf "\n" | pyre init is broken in the manner mentioned above which makes Pyre unusable.

Work around

As of writing, the most recent functional version is 0.0.52. Thus you should be able to pip3 install pyre-check==0.0.52 and continue with your checks, ci, or however you run pyre.

[TylerYep]

Not sure if this is related, but I get the following error trying to run pyre with pyenv:

Invalid configuration: /Users/tyleryep/.pyenv/versions/3.8.5/lib/stdlib is not a valid directory.

EDIT: See #316

[cooperlees]

Not sure if this is related, but I get the following error trying to run pyre with pyenv:

Invalid configuration: /Users/tyleryep/.pyenv/versions/3.8.5/lib/stdlib is not a valid directory.

This is more related to #316 and venv support moving forward.

[pradeep90]

@TomMD @TylerYep @cooperlees I've created #317 since that's a separate issue from the original pyre init issue.

[grievejia]

Closing this since it has been fixed since v0.0.56