Synchronize setup.cfg and pyproject.toml, bump project versions in both, and add 2-line setup.py
#1323
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
This commit adds a 2-line (3-line, if you count the blank line) `setup.py` script that provides the bare minimum needed to support packaging with `setuptools`, e.g.: ```shell python3 setup.py sdist bdist_wheel ``` This basic `setup.py` should also support editable installations, as requested in nschloe#1223. The basic rationale for `setuptools` packaging is for high-performance computing sites that lag behind in software tooling. While projects like Spack help update this tooling to permit updating sometimes ancient toolchains, HPC site policies -- including the HPC site I work at -- sometimes require repackaging Python packages from source for internal approval and security auditing, as well as for portable installation to air-gapped machines. While I completely agree that `setup.py` is a relic -- and to that effect, just spent a few hours adding source code and binary wheel installations of `flit_core`, `flit`, `pep517`, and `build` to my HPC site for approval -- it's much, much easier to point to upstream code than it is to have to figure out that these lines must be added for bespoke packaging, add them, look through project documentation like `CONTRIBUTING.md`, discover through looking at pull requests and issues on GitHub that such a pull request may not be accepted, and then figure out how to pass that information on to security auditors and colleagues. If this solution is unacceptable, I welcome other suggestions, including writing a statement to the effect of "Pull requests adding a `setup.py` file will not be accepted to this repository" somewhere in documentation, along with the suggested solution of adding ```python from setuptools import setup setup() ``` or similar to a local copy of the repository so as to avoid the sorts of discussions seen in nschloe#1224.
This commit synchronizes the numpy version requirement from pyproject.toml to the setup.cfg file. I'm not sure whether this approach is correct, but it's simple enough to do, and should yield the same results via `setuptools` or via `pyproject.toml` approaches such as `build` or `flit`.
This commit synchronizes the `pyproject.toml` file settings with the amended version of `setup.cfg` that updates the `numpy` version requirement. The rationale behind this synchronization is, again, to make a `setuptools`-based installation reading (mostly) from `setup.cfg` behave the same way as a `build`- or `flit`-based installation.
This commit bumps the project version in both `pyproject.toml` and `setup.cfg` to 7.0.1, based on the last release tag in the `meshio` upstream Git repository at `https://github.com/nschloe/meshio/issues`. There is also a `meshio-rewrite` project on PyPI that seems to be at version 7.0.6, but it is unclear to me whether that version is related to the upstream `meshio` repository above, because the linked homepage for that PyPI entry is inaccessible.
|
What about using setuptools_scm to automatically generate version from latest tag? |
|
If maintainers want me to make those changes, I’m happy to do that. I’m also willing to drop |
|
Closing due to inactivity. |
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.
Summary
This pull request does three things:
setup.cfgandpyproject.tomlsettings so that installing from source viabuilddoesn't yield an installation with a stale version like5.0.0.setup.cfgandpyproject.tomlfrom5.3.4and5.0.0, respectively, to7.0.1, reflecting a patch version increase above the most recent tag and release on GitHub.setup.pyscript.Rationale
The current project metadata in both
setup.cfgandpyproject.tomllooks stale, and the data in each is in conflict. Synchronizing them would make dependency data and other metadata clearer to contributors and packagers.The 2-line
setup.pyscript is intended to ease repackaging of the project. I work at an HPC site and have to convert mesh data amongst multiple formats. This package makes my life much easier, and I am grateful for all the work that has gone into it. In order to use it on some on-site projects, I need to repackage the project from source, ideally both as a wheel and as a source distribution, for security auditing and approval. Part of the rationale for source repackaging is to enable portable installation on air-gapped systems. Given the sometimes ancient software toolchains used at HPC sites, it is much easier to repackage software withsetuptoolsthan it is to usebuild. To wit, I spent several hours today repackagingflit_core,flit,pep517, andbuildto submit for approval and auditing as a fallback plan in case this pull request addingsetup.pyis rejected. While I wholeheartedly agree that getting rid ofsetup.pyis a good thing, adding the two-line version is a pragmatic alternative, particularly because it is easier to get approval where I work for code incorporated into an upstream project than it is to carry around a bespoke patch.Alternatives
setup.py, if the goal is to avoid adding it to the project now and in the future, a simple expedient would be to document that policy inCONTRIBUTING.md. If that is indeed project policy, I am happy to add such text to that file. I saw the discussion in Add developer install instructions #1223 and Add back setup.py for editable installations #1224 also, but I suspect other potential contributors may not see this discussion.meshio-rewriteproject on PyPI, but the homepage listed at https://github.com/meshpro/meshio is inaccessible, and it's not entirely clear to me what the relationship of that project is to this one. If the version of the rewrite is indeed 7.0.6, then perhaps these contributions need to be added to that repo instead, or maybe the version number used in this pull request should be different from version 7.0.1.buildandflitboth usepyproject.tomldata by default. If the goal is to move away fromsetuptools, it may be worth getting rid ofsetup.cfgaltogether in favor ofpyproject.toml, though it's not clear to me how the ParaView meshio plugin would be distributed usingpyproject.toml, given its lack of support fordata_files.