On 07/04/2012 06:07 PM, William Stein wrote:
> On Wed, Jul 4, 2012 at 11:45 AM, Michael Orlitzky <mich...@orlitzky.com>
> wrote:
>> On 07/03/12 23:06, Keshav Kini wrote:
>>>
>>> IMO it's usually better to depend on someone else's code than to absorb
>>> it, because then you can more easily pick up bugfixes later, and also it
>>> makes it clearer that we are benefiting from their work. To choose
>>> absorbing code instead of depending on it simply because it's small and
>>> maintaining a package seems like a non-zero amount of work seems to me
>>> like the wrong thing to do.
>>>
>>
>> I agree with this. It's a better long-term solution.
>
> Added the code as an spkg or to the Sage library unchanged (without
> adding doctests) is equivalent from this perspective. Code put in the
> sage library as a file unchanged is no more or less "absored" than
> code put in an spkg.
Sure it is. It makes it explicit that the package is standalone; i.e.
not developed as part of sage. A few benefits:
1 Developers are less likely to hack directly on the code.
Modifications are kept in patches and either forwarded upstream,
or kept separate as an indication that the changes are
sage-specific. When upstream makes changes, it's clear what needs
to be rebased.
2 Somebody will occasionally check upstream to see if any improvements
or fixes have been made.
3 We maintain a build system that integrates the code with the sage
library. If the code is at all non-trivial, it's nice to have it in
a script rather than having to figure it out again the next time
someone wants to sync with upstream.
4 Some licensing issues are avoided, e.g. you don't have to
distribute upstream's LICENSE file with the sage library.
5 You make it easier for distros to include sage.
6 Principle of least surprise: most (all?) other external projects
are distributed as SPKGs, so this one should be too unless there's
a good reason not to.
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
