My 5 cents:

* Magma is not a spkg. 

* Library code that depends on optional / third-party software uses the # 
optional - foo mechanism.

* Python / cython code in spkgs: Fine, just don't use the sage.* namespace.

* Python / cython code that you want to put into the sage.* namespace: Use 
a git branch. If that requires a spkg / third-party code, put that into the 
git branch as well (*)

(*) Optional spkg-in-git can't specify alternate download locations yet, so 
you have to manually put the tarball into the upstream/ directory.






 

On Wednesday, December 11, 2013 1:41:59 PM UTC, Jean-Pierre Flori wrote:
>
> Hi all,
>
> Do we have any policy concerning integration of python/cython glue into 
> the Sage library which depends on optional spkgs or third party software 
> shipping mostly independent code?
> And what about optional spkgs which are actually mostly python/cython code 
> ?
>
> It seems to me that in the former case the python/cython glue is directly 
> integrated into the, e.g. cryptominisat or magma.
> In the latter case one crafts a custom setup.py file to compile/install 
> the cython/python files, e.g. p_group_cohomology or ore_algebra.
>
> I should be giving a short talk on spkgs next january and I'm not sure 
> what to say about this point.
>
> Best,
> JP
>

-- 
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to