PySol FC: more than a thousand solitaire games, still running on Tkinter

A game collection measured in thousands, where the rules are the source

PySol FC is described as a comprehensive, feature-rich, open source and portable collection of Solitaire games written in Python, and the packaging metadata in the repository gives the scale precisely: more than 1200 solitaire card games.

That number is the product. A commercial solitaire collection might offer a few dozen layouts, because each one is hand-designed art and a hand-written rule set. PySol FC reaches four figures because a PySol variant is mostly data: a layout description, a set of rules, and the piece of code that implements the mechanics it needs. The repository layout reflects that, with the rules and the game metadata living in the same tree as the engine, and the Makefile containing a target that regenerates the games documentation from those descriptions.

The interface is Tkinter, and the requirements state Python 3.7 or later with Tkinter, meaning Tcl/Tk 8.4 or later. The project history is in the documentation too: the GitHub branch is the maintenance branch of PySol FC, maintained by Shlomi Fish and other contributors, and it has gained official status, ported the code to Python 3 and implemented further enhancements over the original PySol.

The feature set, as the packaging description lists it, includes a modern look using the Tile widget set, multiple cardsets and tableau backgrounds, sound, unlimited undo, player statistics, a hint system, demo games and a solitaire wizard. A wizard that generates a random layout for you is the feature that turns a catalogue into a daily habit, and unlimited undo is the feature that makes an unsolvable layout a puzzle rather than a lost session.

Running it from source, and the dependency list that is still of its era

The simplest way in is to run it from the source directory:

python pysol.py

The fuller install route in the documentation is written out per distribution, and it tells you a lot about the project's age. On Fedora:

sudo dnf builddep PySolFC

On Mageia:

sudo urpmi git make pygtk2 pygtk2.0-libglade gnome-python-canvas tkinter

And on Debian, Ubuntu and derivatives:

sudo apt-get install cpanminus make perl python3-setuptools python3-tk

The Mageia line still installs pygtk2 and gnome-python-canvas, which are the GTK-era rendering libraries, while the current interface is Tile on Tk. The dependency set carries the residue of a project that has been ported forward over many years and kept the older paths working.

The Linux build sequence in the documentation is a full from-source install:

git clone https://github.com/shlomif/PySolFC.git
cd PySolFC
# Now make sure you have installed the dependencies.
gmake test
gmake rules
ln -s data/images images
tar -xvf PySolFC-Cardsets-3.0.tar.bz2 # Needs to be downloaded from sourceforge
mkdir -p ~/.PySolFC
rmdir ~/.PySolFC/cardsets
ln -s "`pwd`/PySolFC-Cardsets-3.0" ~/.PySolFC/cardsets
python pysol.py

The cardsets archive is not optional and it is not in the repository. The card art lives in a separate tarball on SourceForge, and the documentation is explicit about a trap: on a Debian derivative, installing the cardsets package removes files that pysol from source needs, and the symptom is an error saying that no cardsets were found and to check the installation. The documented fix is to uninstall that package and use the SourceForge archive with the symlink dance above.

Two optional extras are worth knowing about. The virtual environment route installs a pysol-cards package, needs libjpeg headers for the Pillow build, clones the repository, creates a venv and runs the install script, but the documentation states that it currently works only on POSIX systems, so Windows and Mac users have to bring their own script. And the cardsets and music both go into ~/.PySolFC, as ~/.PySolFC/cardsets and ~/.PySolFC/music, with the original PySol music downloadable from the SourceForge files area.

Two toolkits, one game engine, and an Android package

The alternate toolkit is the part of the project that shows how a long-lived desktop application stays reachable.

Kivy is supported as an alternative, and the two listed features are sound support integrated and Android apk build support. Running from source with it is a single flag:

python pysol.py --kivy

On the basis of Kivy an Android application is also available, and the documentation says you can build your own using the build instructions in README.android and in the buildozer directory, with the buildozer/ directory present in the tree. Some versions are also published on F-Droid, under the package id org.lufebe16.pysolfc, and the repository carries fastlane/ and appdata.xml, which are the metadata files an Android store listing needs.

So the same game logic runs under two very different toolkits, and the reason is historical. Tkinter is what the original PySol was written in, and it remains the primary interface because it is in the standard library and needs nothing to be installed. Kivy was added to reach phones, where Tkinter does not exist, and the alternative toolkit path exists so the game rules are not reimplemented for a new environment.

The Windows story is separate again: there is an installer for Windows on SourceForge, which requires Windows XP SP3 or higher, and the repository carries an .appveyor.yml, a .travis.yml and a GitHub Actions workflow, so the project is tested on all three platforms in some form.

The language side is also handled with real tooling rather than ad-hoc strings. The Makefile has pot and mo targets that extract translatable strings with xgettext and compile message catalogues with msgfmt, and the languages handled there are de, fr, pl, it, ru and pt_BR, with the locale/ and po/ directories in the tree and a perltidyrc and tidyallrc for the Perl parts of the build.

The solvers, and the difference between a game collection and a solver

The optional package list includes the Freecell Solver and the Black Hole Solitaire Solver, and both are listed with their own project pages rather than as bundled features.

This is the clearest illustration of how the project is put together. PySol FC is the game: the layouts, the rules, the animation, the statistics, the card art. The solver is a separate program, maintained separately, that takes a position and tells you whether it can be won and how. The Freecell Solver documentation explains the integration as configuration of the solver's CMake-based build system, with the options -DMAX_NUM_FREECELLS=8, -DMAX_NUM_STACKS=20 and -DMAX_NUM_INITIAL_CARDS_IN_A_STACK=60.

Those three numbers are the contract between the two projects. A layout in PySol FC that uses more free cells or more stacks than the solver was built for cannot be verified, so the solver has to be compiled to match the game rather than the other way around. That is a real operational detail, and it is the kind of coupling that a self-contained implementation would not have.

The difference in approach between the two is worth stating plainly. A solver is a search program: it takes a position, works through the move space, and returns a solution or a proof that there is none, with no interface beyond that. A game collection is an environment: it manages cardsets, themes, sound, statistics, undo and a wizard, and it can call a solver when a layout is hard. Using PySol FC because a layout is unsolvable, and then using the solver because the layout might not be, is the intended division of labour.

The other optional dependencies follow the same pattern of a base program plus separate components. Pillow handles images, TTKThemes supplies alternative tile themes, and Accessible Output 2 is listed for screen reader support, which is a dependency few game projects of this age carry. Sound comes either from a PySol-Sound-Server fork handling mp3, wav and tracker music, or from PyGame or PyGame CE, which handles mp3, ogg, wav, midi and tracker music.

Maintenance: a maintainer who stepped down and a project still shipping

The call for contributors in the project documentation is the most important paragraph in the file, and it is unusually direct.

Shlomi Fish, who adopted PySol FC and maintained it for several years, has stepped down as its primary maintainer because he no longer plays PySol, or other computer card games, too much and it had become a time sink for him. The project says it is looking for other contributors and that there are still some large-scale features that can be implemented, with a link to the issue tracker for those.

The delivery record since then is still real. The recent releases are pysolfc-3.6.1 from 2026-07-19, pysolfc-3.6.0 from 2026-06-14 and pysolfc-3.4.1 from 2026-02-10, and the last push to the repository was on 2026-10-19. So patches and a minor version landed in the summer and the source is being worked on in the autumn. The tree also carries the continuous integration configurations, a CONTRIBUTING.md, an AUTHORS.md, a COPYING file and a NEWS.asciidoc changelog.

The consequence for a user is a project with an unusual shape: the code is mature, the community infrastructure is complete, and the person who ran it has left for a reason that has nothing to do with the code's quality. Adoption decisions should reflect that. A large, well-tested collection that is looking for a maintainer is a good project to contribute to and a riskier project to depend on, and the difference between those two positions is worth being deliberate about.

On the licence side, the project is distributed under the GNU General Public License v3, which is a copyleft licence, and the COPYING file in the tree is the licence text. For a personal installation that has no practical consequence. For anyone who wants to redistribute a modified collection, the obligations come with the licence.

Where PySol FC is the wrong tool

The first limit is the interface. Tkinter is the primary front end, and a Tk application on a modern desktop looks and feels like a Tk application, with the widget-level conventions of the 1990s rather than the current platform. The Kivy path exists for phones and for people who want a different look, but it is the alternate route, and the documentation does not present it as a replacement.

The second is the installation story. The instructions for a source install are written per distribution and involve a cardset archive downloaded separately, a symlink into ~/.PySolFC, and a specific warning about a Debian package that breaks the source build. The virtual environment route is documented as working only on POSIX systems, with Windows and Mac users invited to write their own script. None of that is unusual for a project of this age, and all of it is friction a new user meets before seeing a card.

The third is that a solitaire collection is inherently a long-session, offline, single-player activity, and PySol FC is built for exactly that and nothing else. There is no account, no sync, no progression system and no network play, and a player who wants those things is looking at a different category of product.

The fourth is the maintenance question again, in a sharper form. With a thousand plus games and rules stored as data, a contributor is not writing a feature, they are writing a variant description and checking it against the engine. The barrier to adding a game is low and the barrier to reviewing a thousand existing ones is high, which is precisely the shape of project that needs a maintainer and a small group of people who know the format.

And the fifth is the solver coupling, which is an unusual dependency direction for a game. The verification of a hard layout depends on a separately compiled program with its own build flags, and if you want to check Freecell layouts against a solver built with different maximum stack and cell counts, the answers will not match. It is a small thing, and it is the kind of detail that shows how the project grew by accretion rather than by design.

Editorial conclusion

PySol FC is worth installing for a player who wants a large catalogue of solitaire variants in one offline program, because the collection is measured in thousands of games rather than dozens, because the game rules are data in the same repository and therefore editable, and because the solver integrations mean a layout that looks stuck can be checked rather than abandoned. It is the wrong tool if you want a maintained modern game client, and it is the wrong tool if you are not comfortable with a Python and Tk environment. Before you set it up, check three things: that Python 3.7 or later with Tkinter and Tcl/Tk 8.4 or later is available, since the interface is Tkinter and nothing else; that you follow the cardset instructions rather than installing a distribution cardsets package, because the Debian and Ubuntu package removes files the source tree needs and the error you get is a missing cardsets message; and that the project is explicitly looking for contributors, since the long-time maintainer has stepped down and the documentation points at open issues for the larger features that remain.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. shlomif/PySolFC on GitHub