Update how we package hlink #71
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
black has very reasonable defaults, and I don't think that we need to specify all of these settings. Some of them are clearly outdated as well. black is giving the same formatting results with or without these settings.
This moves lots of metadata from setup.cfg and setup.py into pyproject.toml. By using the setuptools-scm plugin, we can get rid of lots of the gnarly package data logic in setup.py, which is great. This does make use of the beta tool.setuptools table in pyproject.toml. So we should keep an eye on that. setup.py is still around for backwards compatibility, but we've done away with setup.cfg completely.
These appear on PyPI and help to organize the packages. I picked two that felt very solid - we use Python 3 and are under the Mozilla Public License version 2.0.
…h the build package - Remove setup.py - Add the build package as a development dependency. I added the requirement >=0.6 because the build package switched to a new TOML parser in version 0.6.0, and I don't think we want to go back further than that in fear of TOML parsing bugs. - Update documentation. I removed some mentions of setup.py in favor of pyproject.toml. I also updated the documentation for building an sdist - `python -m build` is the new command.
Using pyproject.toml to install hlink requires a recent version of pip, so add some notes to the README and developer documentation about remembering to upgrade pip.
|
This looks good to me! |
- Capitalize labels to make sure they look nice on PyPI - Add a Changelog url that points to the GitHub Releases page
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Closes #53 and closes #38.
The goal of this PR is to reduce the complexity of how we handle packaging and installation. Previously, we had packaging metadata spread across setup.py and setup.cfg, and extra settings in pyproject.toml. Now, all of the packaging metadata lives in the single pyproject.toml file and we no longer have a setup.py or setup.cfg file. This also simplifies how we include package data, which was a pretty confusing and gnarly section in setup.py before and now makes use of the setuptools_scm plugin to setuptools.
Python packaging is a confusing subject for me, so I'll try to add lots of detail and reasoning about why I made these changes.
blackfrom pyproject.toml. Many of these seem to be the default. Removing them does not affectblack's behavior on the current codebase. If we run into issues in the future, we can add some of these back into pyproject.toml.python-requiresandclassifiers(for PyPI). Fixed a bug where the license file was listed as LICENSE.rst instead of LICENSE.txt.python -m buildbuilds both a source distribution and wheel in the dist directory. I've added a step to the CI/CD GitHub Action that automatically runs this command at the end of the CI/CD job.pipto the README and developer documentation. We're using some newish features with pyproject.toml, so developers will need a reasonably recent version of pip. Hopefully this is not an issue. I took a look at pip's changelog and it looks like versions from 2019 could handle pyproject.toml-only builds.A couple of additional notes:
[tool.setuptools]table in pyproject.toml, which is a beta feature. This prints out some warnings. My guess is that it's reasonably stable at this point, but it is subject to changes, so we should keep an eye on that. We use this table to tell setuptools how to discover the hlink package and its child modules.buildmodule, but if it starts causing issues or makes it hard for some developers, we should probably just go ahead and add it back in ashlink.testsis included as a module and you can import it from an hlink installation. This may be something we want to avoid in the future. I didn't worry about it for this pull request. It was like that before, and it should still be like that after this PR. In the future maybe we want to move the tests/ directory to the top level and out of the hlink/ directory? I'll make a new issue. See also Enable running tests with just the commandpytest#67, which is tangentially related.