These aren't actually used. Somebody contributed them, but I don't see them being needed. So perhaps we shouldn't keep them around anymore.

Aren't the inputs used by the entrypoint script?

Two separate workflow runs is often hard to track. Instead, I adopted a practice of modularizing the workflow pieces as reusable workflows having the reusable- prefix in their names. This allows embedding everything in all the right places. Let's try this, WDYT?

I will return to this suggestion at a later time.

Why would this be needed outside the container?

Because you've set up a test that modifies the $PATH (#112, 1350b8b).

So I was thinking… Why do we need to check in action.yml to Git even if this modifies it anyway? Why not generate it all, then?

Also, I'd use Python instead of Bash here. Then, it'd be possible to have a dict with data and write it as YAML using json.dump() (because JSON is valid YAML, almost always).

That could work. I've added a Python script that generates the Docker action (9ae1850).

Regarding your related comment:

I think that generating the file is a good idea. It should be possible to write the file without bringing in the PyYAML dependency. But it's not that easy for reading it. Can we make use of yq somehow, and convert YAML to JSON this way, maybe?

I've started by using PyYAML but will think about a way to do this with yq.

This would break the deprecation messages, it seems. Have you checked?

I don't think so. The new inputs don't have defaults, so for example, ${{ inputs.repository-url || inputs.repository_url }} will default to inputs.repository_url and deprecationMessage will be logged.

Why do you check for 'gh-action-pypi-publish' in repo? How about forks that renamed it?

If the workflow was triggered by a PR to this repo (pypa/gh-action-pypi-publish), then the action should build the Docker image. Else, the action should be using the GHCR Docker image.

This is important because workflows in other repos might run the marketplace action on PRs. For example, they might want to smoke test package uploads using DevPI like this:

name: Smoke test workflow in a different repo

on:
  pull_request:

env:
  devpi-password: abcd1234
  devpi-username: root
  devpi-port: 3141

jobs:
  smoke-test:
    runs-on: ubuntu-latest
    services:
      devpi:
        image: muccg/devpi
        env:
          DEVPI_PASSWORD: ${{ env.devpi-password }}
        ports:
          - 3141
    timeout-minutes: 2
    steps:
      - name: Check out the action locally
        uses: actions/checkout@v4
      - name: Install the packaging-related tools
        run: python3 -m pip install build twine
      - name: Create the stub package importable directory
        run: mkdir -pv src/test_package
      - name: Populate the stub package `__init__.py`
        run: echo '__version__ = "0.1"' > src/test_package/__init__.py
      - name: Populate the stub package `README.md`
        run: echo "# Test Package" > README.md
      - name: Populate the stub package `pyproject.toml`
        run: echo "$CONTENTS" > pyproject.toml
        env:
          CONTENTS: |
            [build-system]
            requires = [
              "setuptools == 65.6.3",
            ]
            build-backend = "setuptools.build_meta"

            [project]
            name = "test-package"
            version = "0.1"
            readme = "README.md"
      - name: Build the stub package sdist and wheel distributions
        run: python3 -m build
      - name: Register the stub package in devpi
        run: twine register dist/*.tar.gz
        env:
          TWINE_USERNAME: ${{ env.devpi-username }}
          TWINE_PASSWORD: ${{ env.devpi-password }}
          TWINE_REPOSITORY_URL: >-
            http://localhost:${{
              job.services.devpi.ports[env.devpi-port]
            }}/${{
              env.devpi-username
            }}/public/
      - name: Smoke-test the marketplace action
        uses: pypa/gh-action-pypi-publish@unstable/v1
        with:
          user: ${{ env.devpi-username }}
          password: ${{ env.devpi-password }}
          repository-url: http://devpi:${{ env.devpi-port }}/${{ env.devpi-username }}/public/

In that case, github.event_name would be pull_request, but the repo name would be different.

As far as handling PRs to/from renamed forks of this repo (pypa/gh-action-pypi-publish), if you have some other way of specifying "this repo" that doesn't include gh-action-pypi-publish, I'm happy to consider it.

This is not the right way of using constraint files. Here's what should be done instead:

If we go with the latest approach of dumping JSON to a .yml file, we won't need to deal with the PyYAML requirement.

Compiling PyYAML on various VMs might be problematic, so I'd pass --only-binary=:all: via pip-opts or even put it into the config. This way, installing would be more predictable on different versions of Ubuntu VMs that GitHub has.

Another concern is that originally, I opted for a docker-based action so that the external runtime is not mutated (that's one of a few reasons). By installing things with pip we violate that promise. I was kinda hoping that it'd be possible to avoid using a third-party dependency at all.

If we go with the latest approach of dumping JSON to a .yml file, we won't need to deal with the PyYAML requirement.

Another thing to consider, provided that it's actually needed (see https://github.com/pypa/gh-action-pypi-publish/pull/230/files#r1619055808), is making a virtualenv managed by this action (in its checkout/tmp dir so that the end-user's projects aren't polluted).

If we go with the latest approach of dumping JSON to a .yml file, we won't need to deal with the PyYAML requirement.

Could you check if using just

would work?

Most of the time, any valid JSON is also valid YAML so GHA should be able to read it...

Alternatively, we could have a template for the YAML file that would be post-processed by Template strings, str.format_map() or even just f-strings.

Any of these would let us avoid having an external dependency.

I was able to get it to work by dumping JSON to a .yml file.