Clyngor with clingo

This is a python package installing a clingo binary along the clyngor package, so the end-user will not have to care about the clingo installation.

The clingo binary is taken for Linux, OSX and Windows on the official release page

Installation

When someone (who doesn't understand "install clingo binary in your path") have to install clyngor, give them that line instead:

pip install clyngor-with-clingo

A clingo executable will appear in their bin. May need root access if the said someone is working at system level.

Maintenance

The package must be updated to use new clingo binaries.

Since clingo 5.4.0, potassco no longer publishes prebuilt per-OS binaries on the clingo GitHub releases page (source tarballs only). For clingo > 5.4.0, binaries are instead fetched from conda-forge, which still builds and publishes real Linux/macOS/Windows binaries for every release, and made relocatable (no conda environment needed at runtime) by fetch_clingo.py:

python fetch_clingo.py <clingo version> [conda-executable]

This must run once per OS (see .github/workflows/build-binaries.yml, which does exactly that on GitHub-hosted Linux/macOS/Windows runners and smoke-tests each binary natively, including a #script (python) block). Notes on the fetched binaries:

• Python scripting (#script (python)) is supported, with the needed Python runtime bundled alongside the binary; Lua is not.

• sqlite3 and tkinter are pruned from the bundled Python runtime (their native deps are huge and pointless inside an ASP solver).

• Releases publish one platform-tagged wheel per OS/arch (Linux x86_64, macOS arm64 + x86_64, Windows x86_64), no sdist -- each wheel stays under PyPI's size limit and users only download their own OS's binaries.

• Script retrieve-clingo.sh <clingo version> / put-clingo-version.sh <clingo version> are kept only for rebuilding older versions (<= 5.4.0), back when potassco still shipped prebuilt archives on GitHub releases.

Use zest.releaser to upload new versions ; be careful to match clingo version with package version.

How to perform this magic

The current solution: faking clingo as a python script

Link to the way of doing that. Thanks !

I end up reproducing the same entry point implementation, using pkg_resource, and it works: binaries are embedded in the package using the MANIFEST.in, and the package only real operation is to delegate command line arguments to the proper clingo binary.

This seems to work, but:

• user has not control over the installed binary (however that package is all about having the user to not have to cope with that, but still… Experienced users should never use it)
• the 3 binaries are sent to the user, and the choice is made at execution time.

The on-the-fly solution: hack upon setuptools to download binary at installation

Method used by pyasp.

Has a lot of drawbacks, such as binary downloading from the client side, and necessity to use --no-cache-dir pip flag to force pip to execute the hack.

The proper but non-working solution: embed a platform-specific binary into a python package

The python part of the package is simplistic (well, there could be no python in this package), be we still need a basic architecture.

platform-specific magic

Setuptools provides since PEP 508 the environment markers, theoretically usable in setup.cfg with setuptools:

[options.data_files]
bin/clingo =
    bin/linux/clingo; platform_system=="Linux"
    bin/macos/clingo; platform_system=="Darwin"
    bin/win/clingo.exe; platform_system=="Windows"

But it does not works. A question has been asked about it, also on SO.

Probably it's because data_files does not support environment markers. Hence this solution has been abandoned.