On Sun, Oct 14, 2012 at 6:13 AM, mark florisson <markflorisso...@gmail.com> wrote: > On 14 October 2012 14:05, Stefan Behnel <stefan...@behnel.de> wrote: >> mark florisson, 14.10.2012 13:59: >>> The problem with minivect as a package is that it caters to different >>> projects, which have different requirements. Cython and minivect are >>> quite closely coupled, and any future change, or in the future any >>> older version may not have the functionality Cython needs, it's not >>> exactly a stable API at this point. >> >> Ok, understood. >> >> >>> For instance Numba needs python >>> 2.7, whereas Cython needs to be compatible with python 2.4. >>> >>> Before releasing minivect I'll verify every time that it doesn't break >>> Cython, but I currently have no real promises for backwards or forward >>> compatibility. And that is really because not all use cases have yet >>> been anticipated, and some really require a change, as I've already >>> seen with Numba. >>> >>> We could list minivect as a dependency, which works for >>> easy_install/pip users, but I just foresee numerous people running >>> into problems that didn't install with pip, and I don't think an >>> exclusion of a 300kb addition is worth any of that. >> >> Fine. In that case, I'm for not making minivect a separate package at all >> but including it directly and considering it a part of Cython (and Numba >> etc.) until there is enough of an interface to make it a reusable separate >> package, or at least to support a separate installation and independent >> update. Basically, if you can't update it separately, there's no use in >> installing it separately. >> >> As long as we handle this so, we should take care to keep the generic parts >> in their separate package directory and the Cython specific parts in >> Cython, and try to keep the interface between the two as cleanly separate >> as possible, so that we can actually reach a point where both have an >> interface. I would guess that the need to support Numba from the same >> source base will encourage this kind of separation anyway. > > Yes, definitely. > >> Note that this means that minivect will fall under the release schedules of >> Cython and Numba (independently), instead of really having its own releases. > > It can have its own releases as well, but currently there isn't much > point :) Minivect can be developed independent of the releases, since > Cython and Numba need to explicitly pull in the changes. Let's make a > habit of squashing the minivect pulls to avoid its history. > > I'll also wait for Dag and Robert to see if they have a (final) > opinion before merging the subtree.
As I mentioned on the pull request, looks good to me. Given the (somewhat) tight coupling with the AST but the desire to use the codebase for multiple projects, a subtree seems to make the most sense (until/if we have some kind of a plugin system). - Robert _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
