[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
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

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

[Glyph]

> On Jun 14, 2015, at 10:36 AM, Oliver Palmer  wrote:
> 
> 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?

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 
> this way.

-glyph


___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python