[Cython] array expressions

[Dag Sverre Seljebotn]

On 08/27/2012 02:05 PM, Stefan Behnel wrote:
> mark florisson, 27.08.2012 13:52:
>> On 27 August 2012 12:40, Stefan Behnel <stefan_ml at behnel.de> wrote:
>>> mark florisson, 27.08.2012 13:13:
>>>> On 27 August 2012 12:06, Stefan Behnel wrote:
>>>>> My experience with lxml tells me that it's often better to keep things
>>>>> separate but integrated, instead of shipping them in a big box. As long as
>>>>> it doesn't hurt too much to have separate tools, we should keep it that
>>>>> way. Those who prefer everything in a big box can use distributions like
>>>>> Sage, or use apt.
>>>>>
>>>>> As for versioning, you can set dependency version ranges in distutils (and
>>>>> friends) which are honoured by install tools like pip. That keeps the
>>>>> installation fully automatic (and definitely not "a lot more pain"). That
>>>>> being said, the best way to handle this is to build a well defined
>>>>> interface between the two components and to keep that alive for a while.
>>>>>
>>>>> For Jenkins, we'd set up separate jobs that build the dependencies and then
>>>>> install them from there before running the integration tests. We could even
>>>>> have dedicated integration test jobs that only run the tests that involve
>>>>> the dependency (and potentially more than one version of the dependency).
>>>>
>>>> Oh great, that works for me as well. I thought Cython's take was to
>>>> avoid dependencies by shipping everything (like Plex and Tempita).
>>>
>>> Those are core dependencies. Plex is actually modified IIRC, and even
>>> compiled. Tempita was specifically chosen because it's so small and can be
>>> shipped.
>>>
>>>
>>>> I'll make minivect distributable, then.
>>>
>>> I think the difference here is that it's an optional dependency. It makes
>>> sense independently as well when used with other tools. And from my distant
>>> view, it seems like it could deserve its own project.
>>>
>>> The code tree looks a bit disorganised currently, with a lot of modules at
>>> the top level. I guess that's what you meant when you said "make it
>>> distributable".
>>
>> Indeed, the idea was that it would be included verbatim in
>> projects/used as a submodule, since it'd be small enough to include
>> and would always be stable and integrated into the main project. That
>> basically means the entire thing would be the package. It'd be kind of
>> nice to allow it both ways, i.e. install as a package, and make it
>> convenient as a submodule. I think that can be managed.
>
> I'd just move it into a package anyway and let projects that want to use it
> as a git submodule move it to an appropriate place during installation by
> appropriately configuring their project specific distutils setup.
>
>
>> E.g. I can see situations where you need to fix a little bug, or make
>> a small change where you don't really want (to wait for) a new release
>> of minivect, but you do want that exact commit for the release of the
>> main project.
>
> Doesn't that apply to more or less all code out there?

Most package dependencies are *a lot* more loosely coupled that Cython 
(w/some features)<->minivect. Since minivect works with an AST and all.

Dag