-
Notifications
You must be signed in to change notification settings - Fork 9
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
Consider implementations found in jaraco.windows #14
Comments
@jaraco looks like we've come full circle, since we started pywin32-ctypes to avoiding depending on pywin32 in keyring :) So we're definitely in favor of collaboration:
We don't have a lot of resources to spend on this, but we will prepare a branch for a better split into core and pywin32. Does that make sense ? |
Yes. That all sounds mostly reasonable. But obviously this relationship will be untenable if I can't readily move code and advance the project and make releases. Is that access you would be willing to share, if even provisionally? |
We can do that as long as there is a discussion before each release (mostly ensuring things don't break our internal usage). Would that work for you > |
Yes, that would be entirely suitable. |
I've done some work on jaraco.windows 3.0 to move all of the API definitions into their own package. I'm planning to split out a separate distribution of this package, something which pywin32-ctypes could leverage as well as possibly other implementations. |
I find myself today wanting to extend the win32cred support to include credential enumeration. I have some reservation contributing this back to pywin32-ctypes because the project seems not to be making any releases (despite active work on the codebase). Additionally, although we've discussed allowing me to contribute and make releases, the discussion seems to have stalled. Finally, I'm concerned that although projects like keyring and jaraco.windows would like to depend on pywin32-ctypes, they cannot really because the project has not made any final releases (only the 0.0.1 release). If published releases aren't the model for development on this project, what is the recommended model? Are there plans to make releases? Is there reason why releases couldn't be as frequent the associated sprints of contribution (in other words, why leave code unreleased when it is committed, stable, and with no identified needs)? I would like to contribute here, but I feel dis-empowered to do so. Let me know how I can help or if I should address my needs separately. |
@jaraco you are right that we should do another release. As for contributions, is there a reason why PR don't work for you ? |
For several years, I've been accumulating ctypes-based Windows APIs in the jaraco.windows project. Last night, when I was extending the Credential Vault support in jaraco.windows, I discovered this project.
I'm excited to see this effort, especially backed by Enthought. I'm particularly pleased with the Travis-CI testing via wine. Nice!
We should combine efforts. I propose we establish a collaborative relationship in which I can contribute directly and make releases.
I have some other ideas for managing the project, too, which I think will strengthen the project:
I'm happy to file those as separate tickets and address them subsequently (and in a sane, incremental progression), but I just wanted to give a hint as to my initial reaction. To be clear, I don't have a lot of time to spend on any open source project, but I would rather that my efforts be shared with the larger community and not held to their own private islands.
I look forward to your comments and feedback.
The text was updated successfully, but these errors were encountered: