On 10/14/2012 03:05 PM, Stefan Behnel 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.
Note that this means that minivect will fall under the release schedules of
Cython and Numba (independently), instead of really having its own releases.
+1 to Mark's proposal, this seems nice.
BTW, I would guess that no-one has tested hg with git subtrees yet?
git subtree is just a utility for pushing/pulling the history of a
subdirectory to/from another repository.
As long as you don't need to update to a new version of minivect, you
shouldn't be affected at all; when you don't actually use the "git
subtree" commands, it's just a normal directory under git control.
But if one needs to fix a bug in minivect when doing Cython development,
I'm guessing hg-git can't help you move the patch upstream (but you can
always just submit a normal Unix diff upstream instead if you don't want
to use git).
Dag Sverre
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
