On Thu, 20 Dec 2012 13:15:38 +0100 Charles Bouillaguet <charles.bouillag...@gmail.com> wrote:
> On 12/20/2012 01:02 PM, Burcin Erocal wrote: > >> What should I do ? Unconditionally include the cython interface to > >> the sage library, and mark all doctests as optional ? > > > > Can you compile the Cython interface without the header files > > installed by your package? > > No > > > I assume the Cython interface needs to be changed whenever you > > update your library. > > Yes, but changing spkg versions requires a ticket, on which the sage > library can also be changed. > > > Which Sage version is used with an experimental package > > cannot be controlled, since Sage just grabs the latest version > > available at install time. Hence, if you keep the interface > > separate from the spkg, you will run into many incompatibility > > issues. > > OK. But then how do the other spkgs do ? > > > Wouldn't it be easier to include the Cython interface in the > > package? AFAIK, Cython's build system improved significantly and > > there is no reason to use Sage's build system for a Cython module. > > Is it possible to patch the sage library when installing an spkg ? > What if the patch fails because the sage library was updated since > the last spkg updatye ??? This seems like asking for trouble, and > incompatibilities. I am not suggesting to patch the Sage library when installing your package. You can put the interface in a separate Cython module which is built by the usual Python/Cython setup.py magic and installed in the system python module directory. Then people will be able to import your module from the Sage command line as usual. > I still don't understand how it is currently done. I don't think there is a well established procedure for this. There is code in the Sage library that depends on optional packages. This works just like you described. modules_list.py already includes some examples. In this case, all doctests will need to be marked optional. Given the fact that there is no way to guarantee that the wrapper code in the Sage library corresponds to the library version available in the package, I don't see how the current practice is better than bundling the wrappers in the package. I can see the benefits of having the wrappers "included in Sage" from a reputation/review point of view. However, this is not on par with the rest of the Sage library code, since this code is hidden behind optional tags and not tested by Sage users or developers regularly. #13540 improves the situation somewhat. But the way optional packages/modules are handled still leaves something to be desired. Especially if we want to promote creating separate specialized packages as a way of distributing research code: https://groups.google.com/d/topic/sage-devel/fcxNrQqVSz0/discussion Cheers, Burcin -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
