search

PASTAplus / web-x

The EDI Website Project
Apache License 2.0
1 stars 1 forks source link

Which uvicorn version? #41

Closed clnsmth closed 1 year ago

clnsmth commented 1 year ago

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 https://github.com/encode/uvicorn/pull/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 commented 1 year ago

"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 commented 1 year ago

I removed debug=True in f19d36f

clnsmth commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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