Skip to content
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

ValueError: invalid literal for int() with base 10 #2

Closed
jasonvriends opened this issue Jun 7, 2021 · 5 comments
Closed

ValueError: invalid literal for int() with base 10 #2

jasonvriends opened this issue Jun 7, 2021 · 5 comments

Comments

@jasonvriends
Copy link

fastapi | File "/usr/local/lib/python3.8/site-packages/gunicorn/config.py", line 611, in Workers
fastapi | default = int(os.environ.get("WEB_CONCURRENCY", 1))
fastapi | ValueError: invalid literal for int() with base 10: '1

@rednafi
Copy link
Owner

rednafi commented Jun 7, 2021

@jasonvriends Hi, I couldn't reproduce your issue. When does that happen? Also, I just released an update with the latest version of FastAPI and Pydantic. Please take a pull and try to run again. Let me know if this issue persists.

@jasonvriends
Copy link
Author

@rednafi thank you for getting back to me. I think the issue was due to my development environment with WSL. I installed Docker Desktop for Windows and the issues with Docker, Docker Compose, etc. all disappeared.

Another question if you don't mind. Is the intention that you would create a folder for each crud operation? i.e. getActivity, getActivities, etc. or would the folder contain all CRUD operations for a single tag?

@rednafi
Copy link
Owner

rednafi commented Jun 8, 2021

@jasonvriends It's all good then. Great. Thanks for the confirmation.

To answer your question, creating a new folder for each crud operation seems really overkill to me. What if you want to develop and extend something where you have to create like 20-30 crud APIs. In that case, creating a separate folder for each action will soon become unmaintainable and your APIs will have to pay the cost of unnecessary imports.

I'd go with a single tag and extend if the necessity arises by domain logic rather than by CRUD actions.

@jasonvriends
Copy link
Author

Thanks.

@rednafi
Copy link
Owner

rednafi commented Jun 8, 2021

Alright. I think the issue can be closed then. Thanks 👍

@rednafi rednafi closed this as completed Jun 8, 2021
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

2 participants