[Cython] array expressions

[Robert Bradshaw]

On Mon, Aug 27, 2012 at 5:47 AM, Dag Sverre Seljebotn
<d.s.seljebotn at astro.uio.no> wrote:
> On 08/27/2012 02:45 PM, Dag Sverre Seljebotn wrote:
>>
>> 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.
>
>
> I think there's a case for having minivect as a git submodule for convenient
> development purposes (so that you can easily sort of refactor Cython and
> minivect together), but that's only a development mechanism.
>
> I.e., Cython first tries to import 'Cython.minivect' (which could be a
> symlink into a git submodule) and if that fails 'minivect', the latter would
> be the normal end-user mode because Cython doesn't bundle minivect.

+1, this seems like the best option to me.

- Robert