#18514: Upgrade of group cohomology spkg
-------------------------------------+-------------------------------------
Reporter: SimonKing | Owner:
Type: defect | Status: needs_work
Priority: major | Milestone: sage-6.8
Component: packages: | Resolution:
optional | Merged in:
Keywords: group cohomology | Reviewers:
Authors: Simon King | Work issues: Create a new-style
Report Upstream: None of the above | package with least effort
- read trac for reasoning. | Commit:
Branch: | ad6cea059d383bbb0a97c8430caca125d2ca78b7
u/SimonKing/upgrade_of_group_cohomology_spkg| Stopgaps:
Dependencies: #18494 |
-------------------------------------+-------------------------------------
Comment (by SimonKing):
Replying to [comment:86 jdemeyer]:
> Replying to [comment:84 SimonKing]:
> > Question to the reviewer: I made the new package depend on
database_gap. In fact, what really depends on database_gap is only the to-
be-created wrapper in the Sage library. Since database_gap is non-GPL, I
think it should only be installed (as a dependency) when the user agrees.
Is that possible with the dependency framework of packages?
> No, that's not possible within the dependency framework. Also, I
personally don't think it's a good idea to add this kind of interactive
install procedures.
Then we might be in trouble. If I understood correctly, the GPL licence
does not allow that a GPL package (i.e. modular_resolution) installs a
non-GPL package without asking the user.
Perhaps I should elaborate on the dependency on database_gap. The code
does not link against database gap. However, it needs to be able to deal
with elementary abelian groups. Sounds trivial, and it can certainly be
solved abstractly, but for now the elementary abelian group is simply
looked up in the small groups library.
Also, since the p_group_cohomology package is some kind of data base for
cohomology rings, it is needed to assign a unique identifier to a group-
with-a-fixed-minimal-generating-set. That is easier with the small groups
library, but the package also allows to assign a name to a group (e.g.,
Co_3 for the third Conway group), and use the name as unique identifier
for some item in the cohomology ring database (the fixed minimal
generating set is stored along with the ring).
> > Or better move the dependency to the wrapper?
> The wrapper will become part of the Sage library, right? So what do you
mean with "move the dependency to the wrapper"?
Similarly to the !MeatAxe wrapper, I plan to use `OptionalExtension()`.
Hence, the Cython code would only result in an extension module under the
condition that both modular_resolution and database_gap are installed.
So, if the current framework does not allow that installation of
modular_resolutions stops for asking the users permission to install
database_gap first, then we can make it so that modular_resolution only
makes sure that meataxe is installed (no problem, both are GPL compatible,
and modular_resolution will build and test fine), and then the
`OptionalExtension()` will depend on both modular_resolution *and*
database_gap.
--
Ticket URL: <http://trac.sagemath.org/ticket/18514#comment:87>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
