package pypolymake

[mkoeppe]

• development at ​https://gitlab.com/videlec/pypolymake
• (old) tarballs at ​https://github.com/videlec/pypolymake/releases
• PyPI page at ​https://pypi.python.org/pypi/pypolymake/

• ​https://gitlab.com/videlec/pypolymake/-/merge_requests/1

See also: #22710: Meta-ticket: polymake

[mkoeppe]

Note, the package currently is a "script" package whose spkg-install calls "pip". Can't make it a "pip" package at the moment because some environment variables need to be set.

---

Last 10 new commits:

​84492b1	polymake build: disable fink
​ef11a12	Merge tag '7.3.beta9' into t/20892/20892
​dbc5d60	Use --without-fink only on Mac OS X
​6156bb9	pypolymake package
​8923490	Update polymake to 3.0r2
​60caf7a	Handle errors. Remove old installation before installing
​7d1fd0a	Run polymake --reconfigure
​91fe2d5	Fixup "-arch" flags on Mac OS X. Increase verbosity
​3310092	Remove pypolymake package for now
​e6b22d3	Revert "Remove pypolymake package for now"

[mkoeppe]

Branch is on top of #20892.

[git]

Branch pushed to git repo; I updated commit sha1. Last 10 new commits:

​8798d7d	Merge tag '7.3' into t/20892/20892
​3837a48	bliss: Use autotoolized package from Debian
​225755e	bliss: Add more info in SPKG.txt
​4b22211	bliss: Use upstream tarball and patches
​3111091	Merge tag '7.3.beta9' into t/20901/upgrade_bliss_package_to_0_73_with_debian_patches__install_header_files_in_location_expected_by_polymake
​1c398a3	Merge tag '7.3.rc0' into t/20901/upgrade_bliss_package_to_0_73_with_debian_patches__install_header_files_in_location_expected_by_polymake
​1d2707c	Use repackaged archive instead of huge patch
​c0c0427	Adjust to changed bliss header file locations
​7b096fd	Merge branch 't/20901/upgrade_bliss_package_to_0_73_with_debian_patches__install_header_files_in_location_expected_by_polymake' into t/20892/20892
​77014a1	Merge branch 't/20892/20892' into t/21170/pypolymake

[git]

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

​b699fb7

Merge tag '7.4.beta1' into t/21170/pypolymake

[git]

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

​069cfb7	Merge tag '7.4.beta3' into t/21170/pypolymake
​dfa9b01	Remove Darwin arch flags hack

[SimonKing]

What is the status? Should it be reviewed? Does it need work?

[vdelecroix]

I am not happy with pypolymake (which is in beta version)... I am hoping to get something reasonable at sage days 84.

You can already install it in sage through PyPI

$ sage -pip install pypolymake

and even the development version with

$ sage -pip install git+https://github.com/videlec/pypolymake.git

(it does not work for everybody, ​including me right now)

[SimonKing]

Replying to vdelecroix:

I am hoping to get something reasonable at sage days 84.

I thought so...

BTW, I'll try to create a pexpect interface to polymake, see #22452. I guess having Python bindings and a pexpect interface at the same time (similar to having libsingular and the Singular pexpect interface) would be a good argument for making Polymake a standard package.

[vdelecroix]

Replying to SimonKing:

Replying to vdelecroix:

I am hoping to get something reasonable at sage days 84.

I thought so...

BTW, I'll try to create a pexpect interface to polymake, see #22452. I guess having Python bindings and a pexpect interface at the same time (similar to having libsingular and the Singular pexpect interface) would be a good argument for making Polymake a standard package.

To my mind, polymake is too fragile (and too big) to become standard, or even optional.

[SimonKing]

Replying to vdelecroix:

To my mind, polymake is too fragile (and too big)

Is "big" a problem? In what sense is it fragile? Does Polymake change its API very often? Does it have too many serious bugs to be useful? Till now, I didn't have that impression, but perhaps I didn't use Polymake intensely enough.

[vdelecroix]

Replying to SimonKing:

Replying to vdelecroix:

To my mind, polymake is too fragile (and too big)

Is "big" a problem?

It does not seem to be that big. However compilation takes a lot of time.

In what sense is it fragile?

This is a more serious issue: compilation is fragile. You need a working perl environment which are configured differently on different computers. See for example ​this sage-devel thread.

Does Polymake change its API very often? Does it have too many serious bugs to be useful? Till now, I didn't have that impression, but perhaps I didn't use Polymake intensely enough.

No polymake is a very neat software! Only installation is delicate.

[vdelecroix]

Notice: I just updated pypolymake to work with polymake 3.1 (and removed the "beta" branch on github)

[mkoeppe]

Moving some tickets to 9.2. This is not a promise that I will be working on them.

[mkoeppe]

Setting new milestone based on a cursory review of ticket status, priority, and last modification date.

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​4470437	Revert "Remove pypolymake package for now"
​286ec3d	Remove Darwin arch flags hack
​b4eb13a	build/pkgs/pypolymake/SPKG.rst: Rename from SPKG.txt, update URL

[git]

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

​b168500	build/pkgs/pypolymake/type: Update to new format of script packages
​565d6de	build/pkgs/pypolymake: Switch to install from git

[mkoeppe]

...local/include/polymake/AnyString.h:43:9: error: delegating constructors are permitted only in C++11

Need to switch on std=c++11 somewhere