Metadata-Version: 2.4
Name: clyngor-with-clingo
Version: 5.8.0
Summary: Installation of clingo binary along clyngor
Home-page: https://github.com/aluriak/clyngor-with-clingo
Author: Lucas Bourneuf
Author-email: lucas.bourneuf@laposte.net
License: GPL
Keywords: Answer Set Programming,wrapper,clingo
Classifier: Development Status :: 4 - Beta
Classifier: Intended Audience :: Science/Research
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3.5
Classifier: Programming Language :: Python :: 3.6
Classifier: Programming Language :: Python :: 3.7
Classifier: Programming Language :: ASP
Description-Content-Type: text/markdown
Requires-Dist: clyngor>=0.3.15

# Clyngor with clingo
This is a python package installing a clingo binary along the [clyngor package](https://github.com/aluriak/clyngor),
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](https://github.com/potassco/clingo/releases/)

# 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](https://github.com/potassco/clingo/releases)
(source tarballs only). For clingo **> 5.4.0**, binaries are instead fetched
from [conda-forge](https://github.com/conda-forge/clingo-feedstock), 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](https://zestreleaser.readthedocs.io) 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](https://stackoverflow.com/questions/24686838/distributing-a-binary-utility-in-setuptools). Thanks !

I end up [reproducing the same entry point implementation, using pkg_resource](clyngor_with_clingo/__init__.py), and it works:
binaries are embedded in the package using the [MANIFEST.in](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](https://github.com/sthiele/pyasp/blob/master/setup.py#L136).

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](https://stackoverflow.com/questions/12461603/setting-up-setup-py-for-packaging-of-a-single-py-file-and-a-single-data-file-wi).


### platform-specific magic
Setuptools provides since [PEP 508](https://www.python.org/dev/peps/pep-0508) the environment markers,
theoretically [usable in setup.cfg](https://stackoverflow.com/questions/44878440/correct-use-of-pep-508-environment-markers-in-setup-cfg)
with [setuptools](https://github.com/pypa/setuptools/pull/1520):

    [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](https://github.com/pypa/setuptools/issues/1728), also [on SO](https://stackoverflow.com/q/56004271/3077939).

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