Remove import of 'ppl' at startup using lazy_import with feature

[mkoeppe]

Currently, sage imports ppl (from pplpy) at startup, via sage.geometry.cone, sage.geometry.integral_points, and sage.geometry.lattice_polytopes.

This should be changed, both

• as preparation for other backends for polyhedral cones (in particular PyNormaliz)
• for the modularization of sagelib (Meta-ticket: Modularize sagelib into separate distributions (pip-installable packages) sagemath-... for Sage 10.x #29705).

In addition we add documentation to the option feature of lazy import and while we are at it, use this option for backend normaliz as well.

CC: @kliem @novoselt @vbraun @w-bruns @jplab @orlitzky @videlec

Component: geometry

Keywords: sd111

Author: Jonathan Kliem, Matthias Koeppe

Branch/Commit: 17c4cdb

Reviewer: Matthias Koeppe, Jonathan Kliem

Issue created by migration from https://trac.sagemath.org/ticket/30587

[mkoeppe]

Changed keywords from none to sd111

[kliem]

comment:3

I'm looking at this at the moment.

I think one needs to also take case of Polyhedron_base, because once it is lazily imported, then it immediately imports all depencies, in particular the stuff from ppl.

So if the goal is to have a working sage as good as possible without ppl, then this should be touched as well.

(I tested adding a line from foo import nonsense into backend_ppl.py. Sage is starting all right, but polyhedra are unusable. However, only backend ppl should fail.)

[kliem]

New commits:

7dae2c0	lazy import polyhedra instances
736f7ae	lazy import ppl for cone
c8cb27a	remove import of ppl through lattice polytope

[kliem]

Commit: c8cb27a

[kliem]

Author: Jonathan Kliem

[kliem]

Branch: public/30587

[kliem]

Work Issues: use feature of lazy import

[orlitzky]

comment:7

If the imports would not wind up in an extremely hot path, you might also work around the circular imports with local ones (from foo import whatever within the function that needs whatever). Those don't get run until the function is called, but it does introduce a tiny redundant dictionary lookup the second, third, etc times the function is called.

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

d8934c0

document feature of lazy import

[sagetrac-git]

Changed commit from c8cb27a to d8934c0

[kliem]

comment:9

So lazy import appears to be a bit slower.

For %timeit polytopes.cube() I went from 411 µs to 417. I don't know if this is acceptable.
So there appears to be a overhead of about 6 µs per call.

---

New commits:

d8934c0

document feature of lazy import

[sagetrac-git]

Changed commit from d8934c0 to 5feb98c

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

5e53333	Revert "lazy import polyhedra instances"
aca03b0	using feature of lazy import for backend normaliz
8bd41ea	lazy import ppl in backend_ppl
a456030	add feature to cone
19bc7e4	add feature option to lattice polytope
5feb98c	missing import

[kliem]

Changed work issues from use feature of lazy import to none

[mkoeppe]

comment:12

In the doctest for lazy_import, this text:

+ To install foo using the Sage package manager, you can try to run:
+        !sage -i non-existing-package

will only appear on sage-the-distribution but not in downstream packaged sage, so it's best to use ... here

[kliem]

comment:13

Ok, I wasn't exactly sure, what part would appear and what part would not.

[sagetrac-git]

Changed commit from 5feb98c to d7a2de9

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

d7a2de9

make the doctest work outside of the distribution

[mkoeppe]

comment:15

In fact, perhaps LazyImport.__repr__ should catch this error and print itself in a friendlier way?

[mkoeppe]

comment:16

Also typo An example of and import : and->an

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

3c7b704

lazily import PyNormaliz

[sagetrac-git]

Changed commit from b3ec686 to 3c7b704

[kliem]

comment:27

Somehow forgot that.

[mkoeppe]

Reviewer: Matthias Koeppe

[kliem]

comment:29

Thank you. So I guess I know how that mechanism works, you can ping me, to do it with other packages.

[vbraun]

comment:30

On OSX:

**********************************************************************
File "src/sage/misc/lazy_import.pyx", line 1073, in sage.misc.lazy_import.?
Failed example:
    not_there
Expected:
    Failed lazy import:
    foo is not available.
    Importing not_there failed: No module named 'foo'
    No equivalent system packages for ... are known to Sage.
    ...
Got:
    Failed lazy import:
    foo is not available.
    Importing not_there failed: No module named 'foo'
    To install foo using the unknown package manager, you can try to run:
    # install the following packages:
    To install foo using the Sage package manager, you can try to run:
      !sage -i non-existing-package
    No equivalent system packages for pip are known to Sage.
**********************************************************************

[mkoeppe]

comment:31

Looks like we never tested the runtime system package advice on macOS without homebrew. unknown needs special-casing

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

81a655e

sage.features.package_systems: Ignore 'unknown'

[sagetrac-git]

Changed commit from 3c7b704 to 81a655e

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

17c4cdb

sage.misc.lazy_import: Add some more '...' to doctest

[sagetrac-git]

Changed commit from 81a655e to 17c4cdb

[mkoeppe]

Changed author from Jonathan Kliem to Jonathan Kliem, Matthias Koeppe

[mkoeppe]

Changed reviewer from Matthias Koeppe to Matthias Koeppe, ...

[kliem]

comment:35

Thanks for the quick fix.

[kliem]

Changed reviewer from Matthias Koeppe, ... to Matthias Koeppe, Jonathan Kliem

[vbraun]

Changed branch from public/30587 to 17c4cdb