-
Notifications
You must be signed in to change notification settings - Fork 33
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
External vendoring #48
Comments
Aside from greenlet, on most platforms gevent doesn't have any required third-party dependencies, it vendors everything it needs (libev, libuv, c-ares, etc). It only has optional dependencies for non-core functions. I didn't want to add a third-party dependency for the critical function of getting tracebacks across greenlets. gevent's a low-level library likely to be deployed in lots of different scenarios and having third-party dependencies can make it more difficult to deploy due to conflicts or even policies. |
Yes but gevent already uses features that require recent packaging tooling (like env markers) - I doubt an external dep is really a problem. All I want to avoid is processes like #42 which make me wonder why I even bother making this a library instead of a blogpost/gist/stackoverflow answer. Because it's effectively that if everyone vendors it. |
Also note that Victor's patch had a regression (a963527). Hassles can be avoided without vendoring. |
So I would like to discuss the vendoring in gevent and understand what needs to happen for this library to stop being vendored. I believe @jamadden can give some input, any suggestions or requirements are welcome.
The text was updated successfully, but these errors were encountered: