On 2017-07-08 13:37, Simon King wrote:
Sure. The meataxe experience was the reason why I tried optional extension
modules. I don't recall *who* said so, but I was told that optional extension
modules in the Sage source tree should only be used for functionalty that exists
in vanilla Sage and can be used with an optional backend (as in the case of
meataxe:
Sage does have matrices over finite non-prime fields of odd characteristic, but
meataxe provides an optional backend for them).
I don't think that it should be so strict. Of course, the optional
module should still be within the scope of Sage and be sufficiently
related to things that Sage does.
Keep in mind that there are advantages to having your code *not* in
Sage, namely:
(1) it might be usable by people who don't have Sage
(2) you can develop it as you wish, no need to go through the Sage Trac
There has been some movement recently to move code out of Sage as
external package. In particular cysignals, cypari2 and fpylll are now
packages which used to be part of Sage. There is a plan to do the same
with the PPL interface too.
That's not necessarily bad. If the documentation of optional stuff is built
by default
It's the opposite. There is no documentation for optional packages.
There are technical reasons for this, I have not really tried to make it
work.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
