Switch from distutils-extra to setuptools and setuptools-gettext #800
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I want to move this project towards a standard Python packaging workflow, using
pip installinstead of the legacy setup.py install. The latter has been deprecated and no longer works out of the box on Python 3.14 (see #795). There also long-standing issues where the current approach doesn't work correctly for local installs, such as #247.Developer workflow
This changes the workflow slightly for developers. Instead of running the
bin/varietyscript, the standard approach is:pip install -e .to install Variety & dependencies in editable mode (i.e. you can make code changes and apply them directly without rerunning pip)varietywithin the virtualenvNote that the setup instructions I've written so far create a virtualenv that inherits from system site packages, as some of the dependencies (namely dbus-python) require development headers to compile correctly. I think this is a reasonable tradeoff for the average user.
Packaging workflow
setuptools is stricter by design in what it installs. Only data files under a code package (variety/ in this case) are installed, so I've moved all the media and ui assets one level in. In my testing, a local development installation loads the assets fine. I double checked this by removing my system wide Variety installation as well.
Packagers will need to adapt to this by manually installing the .desktop file and icon, as they are not handled by setuptools. Alternatively we could symlink the data directory to /usr/share/variety, but I'm not sure other programs would benefit from that necessarily.
Other changes
I have bumped the version to 0.9.0-alpha1, as this is a non-trivial reorganization. I've also gone ahead and removed unused media assets (mainly grep + manual verification as to whether each one is still being used)