[sage-devel] Re: Old-style packages

2017-07-10 Thread Simon King
Hi Jeroen, On 2017-07-10, Jeroen Demeyer wrote: > 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. That would indeed be the case. > Keep in mind

Re: [sage-devel] Re: Old-style packages

2017-07-10 Thread Jeroen Demeyer
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

[sage-devel] Re: Old-style packages

2017-07-08 Thread Simon King
Hi Jeroen, On 2017-07-07, Jeroen Demeyer wrote: > On 2017-07-07 13:24, Simon King wrote: >> However I was told that the plan to add optional extension modules will not >> be supported. > > Who has said this? We do currently have several optional extension > modules (in

Re: [sage-devel] Re: Old-style packages

2017-07-07 Thread Jeroen Demeyer
On 2017-07-07 13:24, Simon King wrote: However I was told that the plan to add optional extension modules will not be supported. Who has said this? We do currently have several optional extension modules (in particular, one implementing matrices using meataxe, where you were involved in

[sage-devel] Re: Old-style packages

2017-07-07 Thread Simon King
On 2017-07-06, Dima Pasechnik wrote: > There is also Simon's package about group cohomology, with an upgrade still > in the works IIRC. Yes. At some point I had the plan to make a separate new-style package for the C-code of my spkg, put the GAP- and Singular-code of my spkg