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

Modernize pyspedas packaging tools #1032

Open
jameswilburlewis opened this issue Oct 8, 2024 · 6 comments
Open

Modernize pyspedas packaging tools #1032

jameswilburlewis opened this issue Oct 8, 2024 · 6 comments
Assignees
Labels
deprecated packaging python Issues involving Python and Python-related tools outside of pyspedas QA/Testing refactoring

Comments

@jameswilburlewis
Copy link
Contributor

jameswilburlewis commented Oct 8, 2024

Using setup.py files to build releases, as we currently do with pyspedas, is deprecated, and probably won't pass muster with upcoming PyHC tiering requirements or PyOpenSci reviews.

We should explore moving to something more modern, like pyproject.toml or some of the other packaging tools that are in use.

Some options are listed here: https://packaging.python.org/en/latest/guides/tool-recommendations/

@jameswilburlewis jameswilburlewis added QA/Testing python Issues involving Python and Python-related tools outside of pyspedas refactoring deprecated packaging labels Oct 8, 2024
@jameswilburlewis jameswilburlewis self-assigned this Oct 11, 2024
@Beforerr
Copy link
Contributor

For comparison of python packaging tools https://www.pyopensci.org/python-package-guide/package-structure-code/python-package-build-tools.html

I have some experience of using pdm and would love to contribute if we decide to switching to that.

@jameswilburlewis
Copy link
Contributor Author

I looked at the pyopensci page you linked, and pdm does seem like a pretty solid choice

@jameswilburlewis
Copy link
Contributor Author

In addition to switching to a different set of build tools, there is probably room for improvement in our release management workflow.

Right now we build new releases from the head of the main branch, editing release name strings in the various config and metadata files. We probably should make separate release branches to have more control over what changes go in what releases, and take the release string from a git tag on the release branch. It seems pdm has some good built-in support for this.

See also:

#1037 : Minting a DOI and including it in the release metadata should be part of our release workflow

#1031 : We should test each release candidate build "as built", not just from a git clone as our current Github actions do. So: build the package, release to test-pypi, then install and test in a fresh environment. Then, if the tests are all passing, we can finally push it to production pypi.

@jameswilburlewis
Copy link
Contributor Author

We have an initial pyproject.toml file now (thanks @Beforerr!) that's set up for the PDM build backend. There are still a few issues to sort out before putting it into production. (And I think we'll need to switch it temporarily to the setuptools backend, so pip install continues to work as desired? We need to check that before putting out any new releases that include this pyproject.toml.)

@Beforerr
Copy link
Contributor

Beforerr commented Nov 1, 2024

With pdm we could just use pdm install

@jameswilburlewis
Copy link
Contributor Author

Latest pyproject.toml replaces MANIFEST.in and setup.py. Next step will be to start using PDM as the build tool.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
deprecated packaging python Issues involving Python and Python-related tools outside of pyspedas QA/Testing refactoring
Projects
None yet
Development

No branches or pull requests

4 participants