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? Stefan _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
