Should this action pre-install wheel?

[dhimmel]

I recently got this action to succeed as part of a release deployment workflow in dhimmel/pubmedpy@f554a06. However, I had to manually install wheel:

      - name: Install dependencies
        run: pip install wheel
      - name: Build package
        run: python setup.py sdist bdist_wheel

Without pip install wheel, I got an error that bdist_wheel was not a valid command/option.

It seems that many users of this action will need to build a wheel... should wheel be pre-installed by the action?

[webknjaz]

That's by design. This action only intends to publish dists (hence the name). You can put the artifact in place any way you want. Not everyone builds dists in the same way and also you often want to put a testing step between building dists and publishing them. And finally, this action intends to follow UNIX philosophy — do one thing and to it well.
Besides, the whole point of GitHub Actions is to provide simple building blocks which users can then easily reuse in their workflows, like Lego bricks.

P.S. If I were to build an Action for building dists, I'd use PEP517 to invoke the build system instead of locking in the implementation detail.

[dhimmel]

Thanks @webknjaz for the reply. I don't fully understand your points (the specifics of Python packaging are a bit of a mystery to me).

When my workflow ran python setup.py sdist bdist_wheel, it created two different files (a .tar.gz sdist and .whl bdist_wheel) on PyPI:

This action only intends to publish dists (hence the name).

Are you saying that bdist_wheel is not a "dist"? The action name of gh-action-pypi-publish seems to refer to publishing to PyPI, and as the screenshot above shows, the action seems to have published both the sdist and the bdist_wheel.

[webknjaz]

@dhimmel whl is a binary distribution package, sdist (tarball) is a source distribution package. They all are dists.

You're running setup.py sdist bdist_wheel command which effectively builds both (creates a zip and a tarball archives in dist/ directory). That is a build step which is out of scope of this Action. And wheel is a dependency of this out-of-scope command.

You used setuptools to build dists. https://www.python.org/dev/peps/pep-0517/ and https://www.python.org/dev/peps/pep-0518/ introduce a better standard of doing this which may or may not call setuptools but that's out of scope now and is completely up to you.

[dhimmel]

That is a build step which is out of scope of this Action

Okay, so you are saying that dists should be built before this action.

Do you have any workflows that I could reference that first build dists for a python package and then pass those dists to gh-action-pypi-publish to publish? I'm trying to figure out the best way to build than publish a python package using GitHub actions.

[webknjaz]

Well, there's one which is tox-based that uses pep517 package + pyproject.toml to build dists: https://github.com/sanitizers/octomachinery/blob/master/.github/workflows/publish-to-test-pypi.yml.
The commands that tox invokes are in tox.ini.

Basically, your goal is to build dists and put them into dist/ directory. Then, pypa/gh-action-pypi-publish will find and publish those.

[pradyunsg]

Okay, so you are saying that dists should be built before this action.

Yep. This action is specifically scoped to only handling uploads. There's a very clear standard way for doing that and there are no project-specific quirks to take care of with it. :)

That's not true for building a package for projects, which can take many forms and have varying requirements.

---

w.r.t. building packages, I think what you're doing right now makes sense, given that you're using setuptools.

We are trying to figure out a better, more generally applicable answer for "how do I build a package to upload to PyPI" for end users but given that basically everyone working on Python packaging is volunteering their time, it'll take some time to actually have a better answer. :)

[dhimmel]

Got it. Thanks @webknjaz and @pradyunsg for the clarification and examples of resources for building packages.

given that basically everyone working on Python packaging is volunteering their time, it'll take some time

Definitely! Still super impressed with the PyPI progress like markdown description files, API tokens, and the new web interface. Seems like there is still some more I can learn regarding using the most modern tools for building distributions.