Hi Jeroen, On 2016-08-17, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote: > On 2016-08-17 21:32, Simon King wrote: >> It will provide a C library > > I would *not* recommend putting C libraries in Python packages.
I did not suggest that the C library is provided by a *Python* package. Slightly elaborating on my suggestion: Split the code from the old-style p_group_cohomology-2.1.6.spkg into four parts, namely 1. an optional package "meataxe", which provides a C library and some executables and which is *not* a Python package. It is useful for Sage's matrix arithmetic and thus is wrapped by OptionalExtension in the Sage library 2. an optional package "modular_resolution", which depends on meataxe, provides a C library and some executables, which is *not* a Python package and which is of no use without 3. and 4. 3. Gap and Singular library functions, that certainly should be installed into SAGE_ROOT/src/ext/gap resp. .../singular (should it not?), and a data-base of cohomology rings 4. Cython/Python code that depends on 1., 2. and 3., and shall either be OptionalExtension in the Sage library (but people seem to not like it) or a pip-installable Python package p_group_cohomology, where 3. should be provided as data files either by 2. or by 4. Do potential reviewers agree that my plan makes sense? Or should the modularisation of code be achieved in a different way? Cheers, Simon -- 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.
