Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix CoilSnake's build #297

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

PhoenixBound
Copy link
Contributor

@PhoenixBound PhoenixBound commented Aug 22, 2024

Here we go again... there's been a lot of confusion here so I want to double-check everything and make sure we get it done right, so nothing has to be fixed again for a long time.

This PR seeks to eliminate deprecated parts of the build system and clean up the build instructions.

Recent pushes in the Python ecosystem have led to the standardization of different build systems (setuptools, poetry, flit, whatever else) to share a common metadata format, a pyproject.toml file, in order to make installing dependencies more robust (for build dependencies) and less dependent on setuptools (and on its predecessor distutils, which was removed from the standard library in Python 3.12). As part of this, setuptools has been trying to eliminate most places that directly run setup.py from the shell, in favor of using the standard tools. They've also deprecated and attempted to remove many features that are non-standard, including running test suites.

Having a setup.py file itself isn't deprecated. In fact, as of creating this PR in August, CoilSnake couldn't delete setup.py, because pyproject.toml only supported configuring extension modules in setup.py until a few weeks later (when v74.1.0 released). Only certain uses and fields in the file are deprecated. Despite that, in the current version of this PR, I moved everything I could to the new standardized format (except the extension modules, since the syntax is experimental). I'm not aware of any plans for most of those things to be deprecated, so I'm fine with moving things like the package name back to setup.py to keep the PR minimal.

This PR's a draft for now. Some scattered ideas for what might come next, or might not:

  • Fix version info with setuptools-scm, because it probably doesn't work right now
  • Figure out appropriate reliable changes to the spec file will allow Pyinstaller to work on multiple Python versions. (Nowadays eggs seem to include the name of the CPython implementation and use a version number with no . in it. What's the pattern?)
  • See if automating building the EXE (with a custom build backend or otherwise) is possible/worthwhile
  • Maybe offer a "wheel"-format download option...? (aspirational)
    • Use the stable/limited ABI wherever possible so that one wheel can be used with many Python versions, hopefully making pyinstaller specs easier to write too
      • So far it seems like several changes are needed. Even seemingly basic functions like PyList_Check and PyLong_Check aren't part of the stable ABI, and various ergonomics issues around type names in error messages exist that aren't solved until Python 3.13.
    • Change compression extension modules to be optional? It wouldn't do anything now, but once ccscript is replaced with a pure-Python module, we could have a nearly pure-Python version of CoilSnake (very portable)
    • Research ways to cross-compile extension modules for other platforms? Test building wheels for other platforms using crossenv?
    • This would also require updating the CCScript and CCScriptWriter dependencies to do the same thing
  • If Pyinstaller doesn't work out, check out this incomplete page of alternate recommendations

So far, this works well enough to install the package "successfully." I
haven't tested whether it actually works or not, or whether the git
version number integration works properly, or whether you can make an
EXE. (I used Python 3.10.6 on Windows 10 for testing so far. I know of
issues with the spec file.)

While I was here, I tried moving everything I could out of setup.py and
into the new file format shared by all build systems. Maybe that was a
bit unnecessary... But I figure pyproject.toml is easier to analyze with
tools, for people who want to scour GitHub and identify security
problems in popular packages and stuff like that.
And remove a line of setup.py that I accidentally added while debugging
why some headers couldn't be found in the exhal folder...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant