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

Consider implementations found in jaraco.windows #14

Open
jaraco opened this issue May 11, 2014 · 7 comments
Open

Consider implementations found in jaraco.windows #14

jaraco opened this issue May 11, 2014 · 7 comments

Comments

@jaraco
Copy link

jaraco commented May 11, 2014

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:

  1. Consider decouple the 'pywin32' compatibility from the core API, which would only expose the low-level Windows APIs. Perhaps 'pywin32-ctypes' could still be the package that implements the pywin32-compatible interface. This decoupling would allow alternate implementations (such as some of those found in jaraco.windows) to leverage the underlying API while providing a different, perhaps more friendly, interface (for example, jaraco.windows.filesystem implements os.symlink for older Pythons).
  2. Really use semver for version numbers in the project(s). Releases like 219 or 0.0.1 don't communicate as much useful information as a semver versioned 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.

@cournape
Copy link
Contributor

cournape commented Jun 9, 2014

@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:

  • splitting the pywin32-ctypes into two sub-packages, core and e.g. pywin32-compat makes a lot of sense. It would also help pypy support (replacing core with cffi). We've already thought about using a better api in parallel to the pywin32 (which is often not very pythonic and too thin)
  • we're already using semver. 0.* versions indicates that we don't guarantee backward compatibility yet, as documented in semver v2.

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 ?

@cournape cournape added this to the 0.0.2 milestone Jun 9, 2014
@jaraco
Copy link
Author

jaraco commented Jun 11, 2014

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?

@cournape
Copy link
Contributor

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 >

@jaraco
Copy link
Author

jaraco commented Jun 14, 2014

Yes, that would be entirely suitable.

@jaraco
Copy link
Author

jaraco commented Aug 10, 2014

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.

@jaraco
Copy link
Author

jaraco commented May 7, 2015

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.

@cournape
Copy link
Contributor

@jaraco you are right that we should do another release.

As for contributions, is there a reason why PR don't work for you ?

@itziakos itziakos removed this from the 0.1.0 milestone Apr 28, 2017
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

3 participants