On Mon, Aug 27, 2012 at 5:47 AM, Dag Sverre Seljebotn <d.s.seljeb...@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...@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 _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
