Install aspcud with Homebrew, apk, apt, MacPorts, Nix

Project links

• Homepage
• Repository
• Upstream docs
• Package manager page

Commands and aliases

• aspcud
• cudf2lp

Project history

The official README describes two pieces: `cudf2lp`, which translates a CUDF specification into facts, and the small `aspcud` program, which invokes the required ASP grounder and solver and prints the result in CUDF format. The project is part of the Potassco ecosystem and depends on `clasp` and `gringo` or related Potassco solver tools.

The project ChangeLog records aspcud 1.8.0 as the first official release. Version 1.9.0 added package-solver criteria support, installation targets, a Debian manpage, stream reading, macOS build support, MinGW compilation, and replaced a bash/Python wrapper with a small C program. Later 1.9.x releases moved the project to GitHub, switched to the MIT license, adopted Boost program options, and eventually refactored the application to C++.

Adoption history

The Homebrew input records aspcud in apk, Homebrew, Debian, MacPorts, Nix, and Ubuntu. That adoption follows from its role in package-management research and CUDF/Mancoosi workflows rather than general interactive use.

Because aspcud consumes CUDF and emits CUDF, it can be slotted behind package managers or benchmark harnesses that speak the common upgradeability-description format. The README points to Mancoosi CUDF specifications, criteria, and problem instances as the surrounding ecosystem.

How it is used

The canonical command is `aspcud problem.cudf solution.cudf <criteria>`. A user supplies a CUDF problem and optimization criteria, while aspcud coordinates conversion, grounding, solving, and CUDF-format output.

The README notes that either `misc2012.lp` or `specification.lp` encodings can be selected with `-e`; the former typically handles harder problems, while the latter can be faster on simpler instances.

Why package nerds care

aspcud is package-manager machinery made visible as a Unix package. It matters to distribution people because it isolates dependency solving from the front-end package manager and tests solver behavior against CUDF problem sets.

It also shows the crossover between declarative logic programming and package management: package installability and upgrade criteria become ASP facts and optimization problems rather than imperative resolver code.

Timeline

• 1.8.0: First official release.
• 1.9.0: Adds selectors and criteria support, Debian manpage, install target, macOS build support, MinGW compilation, stream reading, and a small C driver.
• 1.9.1: Adjusts encodings for gringo 4.5 compatibility and updates the manpage.
• 1.9.3: Moves to GitHub, switches to MIT license, adopts Boost program options, and updates CMake requirements.
• 1.9.4: Refactors the aspcud application to C++ for maintenance.
• 1.9.5-1.9.6: Updates dependencies and Boost compatibility.

Related projects

• Potassco `clasp` and `clingo` are required solver/grounder components in the README.
• Mancoosi CUDF specifications, criteria, and benchmark instances are the format and workload context for aspcud.

Sources

• https://github.com/potassco/aspcud#readme
• https://github.com/potassco/aspcud/blob/master/CHANGES.md
• input.source_facts.package-manager