Hi Vincent,
On 2016-08-17, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
> 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")
> }}}
OK, that's basically the same as what one would have to do in an
old-style spkg.
> First of all, it appears that some people want to get rid of .spkg
> tarball.
Which of course is a major issue since one of them is release manager.
> 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)
OK, that's a good point.
> 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.
Does that mean that optional packages are not peer reviewed??? That's a
big step in the wrong direction, IMHO!
And again, how does that differ from maintaining an unreviewed .spkg that
the user can install with sage -p?
Note that I created several versions of my old-style spkg and put it on
the servers in Jena. I didn't bother to open a trac ticket, since it
seemed pointless to me. Fighting against backward incompatible changes in
SageMath took a lot of my enthusiasm, to the extent that I was close to
dropping SageMath.
>> 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.
How to build the C libraries that come along with the P/Cython code?
Should it be two packages (one for the C library and one for the rest)?
>> 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".
Yes. But why is the single command "sage -pip install p_group_cohomology"
better than the single command "make modular_resolution"? OK, you have
mentioned above, that you don't need write access to the Sage root and
you can more easily uninstall.
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.
