On 17/08/16 11:53, Simon King wrote:
Hi Vincent,
On 2016-08-16, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
This is *one* way to do. You can also distribute your package as an
independent Python module. That is to say, you can also move the "Cython
interface part" to your package. One advantage of this approach is that
you will not have to perform "make" to get the interface compiled. Just
$ sage -pip install my_tarball.tgz
The cohomology spkg relies on cimported types from SageMath, including
types from the OptionalExtension sage.matrix.matrix_gfpn_dense. Hence,
it makes no sense whatsoever without SageMath and moreover relies on
SageMath's optional meataxe spkg being installed.
So, does the cohomology spkg qualify as an "independent" Python module?
yes. You can cimport from Sage sources in an "external" (rather than
"independent") module.
Concerning the meataxe being installed you can add at the begining of
the setup.py
{{{
try:
from sage.env import SAGE_ROOT, SAGE_SRC
from sage.misc.package import is_package_installed
except ImportError:
raise ValueError("the package XYZ is a Sage package...")
if not is_package_installed('meataxe'):
raise ValueError("whatever")
}}}
If it does, several questions arise:
1. Why is "sage -pip install my_tarball.tgz" better than "sage -p
my_tarball.spkg"? In other words, why should one change an old style
spkg into a pip-installable package?
First of all, it appears that some people want to get rid of .spkg
tarball. Secondly, it is cleaner (see below).
3. A major pain in the neck are "internal" changes in Sage that used to
break my old-style spkg. Would it be easier to cope with them when
using pip or when putting the Cython code into the Sage tree or when
keeping it as an old-style spkg?
It is much better for installation:
- if there is no OptionalExtension then there is no need for an extra
make inside the Sage source code (that might even be impossible if you
have no write access to the Sage install)
- pip allows installation in the user space with "sage -pip install
--user my_package" (otherwise the installation needs write access to the
sage root)
- pip has clean uninstallation and upgrade procedures
It is a bit better for dealing with backward compatibility:
- if there a problem, you do not have to fix anything in the Sage
sources. Just release a new tarball. In particular you do not have to
wait for a new Sage release including the changes.
And I strongly agree that Sage "core" development should pay more
attention to optional packages.
2. How to make the package pip-installable? Can you point me to a
"howto" that also addresses interrelations with Sage, as mentioned
above?
pip installable just means that there is a setup.py file at the root of
the tarball.
3. What do you mean by 'you will not have to perform "make"'? In an
old-style package you wouldn't need to perform "make" either. Why do
you think that "sage -pip install p_group_cohomology.tgz" is better
than "make modular_resolution", where "modular_resolution" will be
the optional new-style spkg that the proposed `OptionalExtension`s in
sage.groups.modular_cohomology are supposed to rely on?
The extra "make" just concerns the OptionalExtesion part. Not the "sage
-pip" versus "sage -p".
Best,
Vincent
--
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.
