It seems that using setup.py is deprecated in favor of using either setup.cfg or pyproject.toml. As of PEP 621 you can store your project metadata in pyproject.toml, since I am basically already doing that I don't see why I shouldn't more formally use it.

I do think I would need to keep using setup.py to build the C extension, but everything else can be moved to pyproject.toml. This should eliminate having to keep both files up to date with each other, which I already forgot about once.

This does bring about an interesting situation. Poetry does not currently support PEP 621, so while it stores metadata in pyproject.toml, it does not yet support storing the project metadata there, in the standardized way. This isn't a total dealbreaker, as I could just manually add the info needed. But I also could migrate to something like PDM.

There are a few thoughts I have regarding what tool to use:

1. For a build backend, I'm going to have to use setuptools because I want to build a C extension. So even if I were to use Poetry's build backend, I would still also need setuptools...so I don't see a strong argument against simply using setuptools.
2. For a frontend, I really like having pip in the scripts (scriptopoly and install). It is very integral in the script commands and I think for what it does, nothing more than pip is needed (and I suppose setuptools as well) Plus, it is basically included for free when setting up the virtual environment. I like having something more featureful while developing so I can have a better tool for setting up and managing dependencies. Poetry works great here, but moving forward, if it doesn't incorporate PEP 621, I would have to manually do that myself. The whole point of this is to simplify and use the approach that is going to be supported moving forward. It would seem to me I'd only be accomplishing the latter, and not even totally, with Poetry (for the time being, until it does add support for PEP 621).
3. This is where PDM comes into play. It does dependency management like Poetry and Pipenv, but it is also PEP 621 compliant. I know I came across it a while back when it was relatively new. Now it seems to have grown and looks like it would be nice to work with. I'm kind of interested in using it just to see how it compares. Virtual Environments are also optional with that, it lets you use a different approach to dependency isolation if desired. I wouldn't need that, but it does seem interesting.

So to sum up, for a build backend, just stick with setuptools since I have a C extension. For the frontend stick with pip in the scripts and switch to PDM for development so I can fully migrate to using pyproject.toml for storing the project metadata and dependencies in the Python blessed way. 🙏

This will produce a bar chart with the results of the simulation. The chart is always produced as an svg image and is produced as a png image for everything except the PyOxidizer binary. There were just too many issues with getting it to work on that so it just isn't going to happen.

This improves handling of keyboard interrupts in the C extension by explicitly checking for any queued signals. It also changes the text output to indicate the simulation was cancelled.

After action-gh-release was updated globs are handled differently. This is because the glob library it uses was updated. The updated glob library always interprets backslashes as escape characters. This means if BUILD_DISTPATH has backslashes in it, action-gh-release won't match it correctly and won't upload our archives. To fix this, we can make sure to always use a posix path.

This adds code signing and notarization to the Github Actions release workflow for macOS builds. This required a few changes to script.py as well. The actual signing is all handled in the script, while adding the certificate and notarization are handled in the release workflow.

Closes #33

With this pull request the Nuitka built binary builds on Windows, woohoo!

There were two problems:

1. The output filename needed to have the .exe extension.
2. The directories for the output file path needed to exist.

The other changes in this pull request are related to upgrading the version of Nuitka

This improves the status indicator on Windows by using a custom class to handle rendering. Using rich created a blinking effect across the whole line while the bouncing bars appeared to skip quite a lot. Not very nice looking. This takes a different approach and brings back much of the old Spinner code, while updating it to only handle Windows, and also using the internals of rich to still create nice looking styles.

Only include the README.md and title-image.png in the site build. For now, all settings can just be configured with the default ones GH pages uses when there is no config.

This was working fine, until it stopped actually building the README.md and now the css is not getting loaded...I think I may merge this and see what happens.

It seems that even though I had gotten the keyboard interrupts working on macOS, they still didn't want to work on Windows when ran in multi-core mode. This change fixes that problem by switching to starmap_async and then manually looping and sleeping until it is ready. This seems to give the interrupts a chance to be processed on Windows while also not adding a performance penalty.

I also tested this on my Mac and the same was true. I won't bother adding a conditional check to only do it this way on Windows since it seems to not have any negative effects on macOS.

Reverts dunkmann00/Monopoly-Probabilities#50

After giving this a test on Windows (which I should have done before merging...) this still doesn't work. Reverting for now.

This adds the Rich package to get nicer looking text output in the terminal. Rich also comes with a spinner so the Spinner from utils is no longer needed.

This also required adding a hash to PyGal's requirements-runtime.txt entry because of how pip handles hashes. If one requirement has it, they all must. In the process of doing this I ended up building a wheel of the PyGal patch so that is what is now used to install PyGal. In the end, this is probably an improvement.

Closes #43

Currently a text and csv file are produced as results from the simulation. I would like to add a visual output like a bar graph and maybe an image of a heat-map over a basic version of the board outline.

• [X] Bar Chart (#42)
• [ ] Board Heat Map

Not sure exactly why this is, but when I try to run the Nuitka binary with multiple cores using multiprocessing it doesn't work. When built in onefile mode it just dies after you try to run it. With standalone mode it sometimes spits out a segmentation fault, and other times it seems to run but error at the end with the following:

/resource_tracker.py:96: UserWarning: resource_tracker: process died unexpectedly, relaunching.  Some resources might leak.

So for now I have just disabled multi-core support for the Nuitka build.

If a user wants to try multi-core mode despite the current problems, they can set the environment variable FORCE_NUITKA_MULTI when running monopoly and it will force it to run in multi-core mode.