[Twisted-Python] Should the CFFI wrapper and functions for win32 be a separate project?

[Oliver Palmer]

As the subject says, could the CFFI wrappers around the win32 functions
that Twisted needs be a separate project? This came up briefly in
https://twistedmatrix.com/trac/ticket/7889 so I thought I might pose the
question to a larger audience.

Generally speaking, the idea of making it a separate project to me seems
like a logical step in many ways. Since the code is not specific to
Twisted keeping it outside of the Twisted project, much like pywin32 is,
makes it easier for contributors and consumers alike to reuse or expand on
the cffi wrapper in the future. I don't think the objective would be to
replace all of pywin32 initially but to provide enough to be usable by the
Twisted project.

Besides Twisted I know there are some other projects out there that could
benefit from making this a separate project. But before taking this
approach however I'm wondering if this would be reasonable from Twisted's
perspective?

---Oliver

[Glyph]

As the subject says, could the CFFI wrappers around the win32 functions that Twisted needs be a separate project? This came up briefly in https://twistedmatrix.com/trac/ticket/7889 <https://twistedmatrix.com/trac/ticket/7889> so I thought I might pose the question to a larger audience.
Generally speaking, the idea of making it a separate project to me seems like a logical step in many ways. Since the code is not specific to Twisted keeping it outside of the Twisted project, much like pywin32 is, makes it easier for contributors and consumers alike to reuse or expand on the cffi wrapper in the future. I don't think the objective would be to replace all of pywin32 initially but to provide enough to be usable by the Twisted project.
Besides Twisted I know there are some other projects out there that could benefit from making this a separate project. But before taking this approach however I'm wondering if this would be reasonable from Twisted's perspective?

I think this would be great.

More generally, now that we have support for setuptools extras, I think we might want to consider moving _all_ C/CFFI/Pyrex code outside of Twisted, and making them optional dependencies. In principle, you should be able to use Twisted without a C compiler, it's just that setuptools has no good way to express that. But it does have (via extras) a way to express optional dependencies, and if we distributed all the native bindings and speedups as separate packages, we could ultimately fix <https://twistedmatrix.com/trac/ticket/3586 <https://twistedmatrix.com/trac/ticket/3586>> this way.

-glyph

[Ray Cote]

Post by Oliver Palmer
As the subject says, could the CFFI wrappers around the win32 functions
that Twisted needs be a separate project? This came up briefly in
https://twistedmatrix.com/trac/ticket/7889 so I thought I might pose the
question to a larger audience.
Generally speaking, the idea of making it a separate project to me seems
like a logical step in many ways. Since the code is not specific to
Twisted keeping it outside of the Twisted project, much like pywin32 is,
makes it easier for contributors and consumers alike to reuse or expand on
the cffi wrapper in the future. I don't think the objective would be to
replace all of pywin32 initially but to provide enough to be usable by the
Twisted project.
Besides Twisted I know there are some other projects out there that could
benefit from making this a separate project. But before taking this
approach however I'm wondering if this would be reasonable from Twisted's
perspective?
---Oliver

I think a separate Windows CFFI project is definitely the way to go.
Allows you to focus on the core interfaces required by Twisted and let's
others focus on their own specific areas of interest without duplicating
effort.
I know we'd make use of CFFI into the Windows Crypto modules, for example.
--Ray