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