abichinger/semantic-release-pypi

semantic-release plugin to publish a python package to PyPI

semantic-release-pypi's Issues

Error: socket hang up

Not sure if this is an issue with semantic-release-pypi or some other issue but when running the verifyConditions step in a GHA ubuntu-latest CI environment utilizing PYPI_TOKEN we get this strange error with no feedback as to what may be causing it.

feat: add option to avoid publishing, only update version in setup.cfg

I am using your plugin and I am very satisfied. Packages are uploaded to our artifactory, version is bumped in setup.cfg and everyone is happy.

When using this plugin for a service, where there is no need to upload an artifact, but only publish an image (with the docker plugin) there is still no option to use it only for bumping the version in setup.cfg.

It would be great if you could add an option to configure the plugin whether to publish an artifact or not and call this plugin as follows (similar to the way npm plugin allows you to):

    [
      "@semantic-release/pypi",
      {
        pypiPublish: false
      },
    ],

workflow: How to get release tag on same commit as updating setup.cfg version

First, thanks for this great library. I'm using semantic-release on my JS and Github Actions repos and am just trying to bring it to my Python ones as well.

I'm trying to figure out how I can get the version tag in the repo to match up with setup.cfg being updated. Right now, I'm using the semantic-release-action to release in Github Actions. Initially, it wasn't saving the change to setup.cfg, so I added a workflow step to commit and push the change. But now, the commit before the one with the version change gets tagged as the released version, so the setup.cfg does not match. The setup.cfg matches after the next commit, but if someone navigates to the repository based on the version tag, they will see the last version in setup.cfg, which could confuse users.

I think this would need to be solved in the library, because making the change to setup.cfg and creating the tag all happen within running semantic-release. For example, perhaps add an option to commit to the branch.

I need the version somewhere, because I build documentation with the version embedded.

If you think this is a good direction, I'm happy to work on a PR. Otherwise, please let me know your thoughts.

feat: add log messages

Error: version in ./setup.py

I get

Error: version in ./setup.py

even though I have a similar setup as in the example: https://github.com/abichinger/semantic-release-pypi-example

setup.cfg is the generated and looks the same as in the example.

Here is my .releaserc

{
  "branches": [
    "master"
  ],
  "plugins": [
    "@semantic-release/commit-analyzer",
    "@semantic-release/release-notes-generator",
    "@semantic-release/changelog",
    [
      "semantic-release-pypi",
      {
        "repoUrl": "https://gitlab.com/api/v4/projects/<my package>/packages/pypi"
      }
    ],
    [
      "@semantic-release/gitlab",
      {
        "assets": [
          {
            "path": "dist/*.whl",
            "label": ".whl"
          },
          {
            "path": "dist/*.tar.gz",
            "label": ".tar.gz"
          }
        ]
      }
    ],
    [
      "@semantic-release/git",
      {
        "message": "chore(release): ${nextRelease.version} [skip ci]\n\n${nextRelease.notes}",
        "assets": [
          "CHANGELOG.md",
          "setup.py",
          "setup.cfg",
          "dist"
        ]
      }
    ]
  ]
}

Weirdly, when running via

 PYPI_TOKEN=<my pypi token> GITLAB_TOKEN=<my gl token> semantic-release --no-ci

it works, but the GitLab CI pipeline fails with the mentioned error.

In both cases I use the same major node version, 18.

Any ideas?

test publish using TestPyPI

assert repository access in verify

pyproject.toml

Hi,

Is there a way to skip the setup.py or use pyproject.toml instead?

verify if function setReleaseVersion affects version

bug: lint fails in setup.cfg after version bump

I am using this plugin in order to upload artifacts and bump versions in setup.cfg.
It seems that this plugin is not only updating the version in setup.cfg, but also edits other parts of the file which fails my linter. For example extra spaces are added to the file as well as a new line at the end of the file.

I would be happy if this could be fixed by only bumping the version field, leaving the rest of the file untacked.

Reading package version from metadata

When making a release, the version number is hard coded. However, setup.cfg allows reading the package version from configuration files for example (if the pckg name is my_package):

setup.cfg

[metadata]
version = attr: my_package.VERSION

Problem: current implementation will override the version in setup.cfg when it should override in VERSION.

convert semver to pep440 version

add keywords to package.json

bug: version check too broad

The verify check for version in setup.py is too broad. It produces false positives if the GPLv3+ header exists in the file:

###########################################################################
# MumbleIce is Copyright (C) 2021 Kyle Robbertze <[email protected]>
#
# MumbleIce is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License version 3, or
# any later version as published by the Free Software Foundation.
#
# MumbleIce is distributed in the hope that it will be useful, but 
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
# 
# You should have received a copy of the GNU General Public License
# along with MumbleIce. If not, see <http://www.gnu.org/licenses/>.
###########################################################################

The version 3, in the line # it under the terms of the GNU General Public License version 3, or line matches. A better regex may be version='[.\n]*',. This is untested however and thought should be given to allowing for spaces around the =.

feat: redirect stdout and stderr of child processes