Hi Jeroen, On 2016-08-18, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote: > On 2016-08-18 00:02, Simon King wrote: >> 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 > > Obviously, it would be better if you could just use the "official" > meataxe package, not Simon King's personal copy.
What are you talking about? The current optional Sage package "meataxe" is the latest upstream from Aachen. >> 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. > > Right. So meataxe and modular_resolution will then be "autotools" > packages, I suppose? Meataxe is what Aachen upstream provides (i.e., no autotools but a Makefile). Modular_resolution is what I provide (i.e., autotools). >> 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 > > Again, packages should not install stuff in the Sage sources. Some personal history might explain why I came up with the suggestion: 0 I started with an old-style spkg, which builds upon code of three parties (one of them being an old meataxe version). 1 SageMath dropped support for old-style spkgs. In the transition to new-style, I started to split the old-style spkg into several parts corresponding to the three parties mentioned in 0, one of them being meataxe --- but switching to the *new* meataxe version. 2 When I created a new-style package for the new meataxe, I was given the impression that a new-style package for a C library should come along with a wrapper in the Sage tree: A standard package such as M4RIE gives rise to an ordinary Extension(), whereas an optional package such as meataxe gives rise to an OptionalExtension(). 3 Because of 2, it was clear that the Sage tree was involved. Additional benefit: Being more closely tied to Sage, my code was less likely to again become broken without notice by internal changes in Sage. 4 Since the Sage tree was involved anyway, it seemed reasonable to me to put certain auxiliary files (with Gap and Singular functions) into the src repository as well. Note that of course they wouldn't be installed there by the package, as they are controlled by Sage's git repository. In the discussion here, I learn: 5 OptionalExtension() should only be used if an optional package affects existing Sage infrastructure (such as matrix arithmetic). 6 The new-style package should do exactly the same as my old-style spkg, namely install the Singular code in local/share/singular/ and provide Cython wrappers outside of the src tree. 7 The idea of future package development for SageMath is to have pip installable packages that are not under peer review, that the SageMath users are not made aware of by SageMath, and that a user can install only if s/he found out where the upstream package is provided. > Especially because your package seems useful even without Sage. Meanwhile we talk about three packages. - meataxe is useful without SageMath, but it is useful to existing SageMath infrastructure, hence affects the src tree. - The upstream code of modular_resolution has never been published outside of the SageMath context. There probably is only one person (the first author, David Green) who would be able to use it without SageMath. I am told here that my idea to let there be wrappers in SageMath's src tree (analogous to meataxe) is evil. - Since I am told that the wrappers do not belong to the src tree, it follows that there has to be a third package, p_group_cohomology. It makes extensive use of SageMath's infrastructure, hence, makes absolutely no sense without SageMath. >> 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. > > I would say: provide it with 2. You could also consider merging 2., 3. > and 4. in one package, since they look closely related (one library + > various interfaces). Aha. So, basically I should just return to the layout of my old-style spkg. Only meataxe becomes separate. Thanks for the advices. Best regards, 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.
