<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Cython is a very open project, and we really try to attract people who want to<br>
contribute, instead of creating new branches for no good reason.</blockquote><div><br>The text at the top of the site should be changed from " Development of Cython is mainly motivated by the needs of
SAGE" in that case :-)<br><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Cython has a much (much!) faster release cycle than Pyrex, and it has an open<br>
development repository (Pyrex also has one by now, BTW).</blockquote><div><br>Last I checked, Pyrex has a tarball of a mercurial image. This does not equate to an open development repository, IMHO.<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
So you can use developer versions with the fixes/features you need even before a new release<br>
comes out.</blockquote><div><br>Again, I don't want this to come across negative, but we're limited to what's been <i>released</i> and in many cases <i>packaged</i> for distros because it's a dependency to build from source. It was a pain for people when we upgraded to Pyrex 0.9.6.x since it broke compatibility with Pyrex 0.9.5.1a with all the __cinit__'s<br>
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I wrote a patch so that you can do that with Cython. You will just have to<br>
care for the dependency tracking yourself, and provide your distutils<br>
Extension with the complete list of sources (including .pxi and .pxd files).<br>
Cython (or rather distutils) will then build only those extensions where any<br>
of the source files in that list has changed.</blockquote><div><br>Thank you for this, but note that it's minor compared to the various functions which search for cimports and the like. We've worked around what it builds a package as (I hope) using the full_module_name argument to compile but this is only the beginning.<br>
<br>Setting the package directory '':'src' would, as I understand it, cause Cython to compile our extensions not as (ie) src.colors.soy.colors but as colors.soy.colors; closer, but still a no-go.<br><br>Honestly I think a distutils.extension.Extension parameter for psources= (etc), treating the Pyrex/Cython/etc sources in a style akin to compiling C sources, compiling each source to a separate .c file, and appending those generated .c files to sources= is a better direction to go<br>
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Is there anything in addition to my patch that you need here?</blockquote><div>
<br>Immediately, the most direct and painless solution would be to handle cimport name searching by only it's file name, rather than it's directory path, to match Pyrex's behavior.<br><br>I'm a huge fan of minimizing hacks, so ideally I'd like a more direct behavior akin to the above suggestion.<br>
</div></div>