Which uvicorn version?

[clnsmth]

Today I installed a fresh web-x and hit an error after running python main.py:

CRITICAL root: Traceback (most recent call last):
  File "/Users/csmith/Code/web-x/main.py", line 71, in <module>
    uvicorn.run(app, host='127.0.0.1', port=8000, debug=True)
TypeError: run() got an unexpected keyword argument 'debug'

This appears to be occurring because my version of uvicorn (0.19.0) no longer supports the --debug flag which exists in web-x@edirepository.org's version (0.18.3). See https://github.com/encode/uvicorn/releases and encode/uvicorn#1640 for details.

One solution is to specify the uvicorn version in the conda environment files. @servilla, I have a pull request ready. I just need to know which uvicorn version you would like used in the web-x project.

[servilla]

"uvicorn>=0.18, <0.19" or conversely, remove the debug=True from main.py on line 71. I think the reasoning outlined in those references is sound, but removing --debug/debug=True breaks backward compatibility. They should have made it a no-op for a few versions and listed it as deprecated. I would remove the debug argument.

[servilla]

I removed debug=True in f19d36f

[clnsmth]

Good point about the deprecation process @servilla. I always find the transition period over a back breaking change to be helpful.

One last thing on this issue: currently, there are a mix of uvicorn version constraints in the environment.yml files. Would you like constraints removed (i.e. change uviron=0.18.3 to uvicorn) so all the environment.yml files are consistent?

[servilla]

The environment.yml is specific to the working Linux OS deployment. Therefore the pinned versions and build ids are critical to maintaining production systems and should not be removed. The environment-min.yml and environment-win.yml are closer to what you (@clnsmth) are looking for where the packages are not pinned and more flexible in an installation across multiple environments (e.g., Windows, OS X, and Linux), thus more consistent. In some cases, the Linux and Windows package dependencies change.

[clnsmth]

Thanks for these clarifications @servilla. It makes sense to leave the environment files 'as is'.