Skip to content

Add PyPI version checking to prevent duplicate version uploads - #59

Merged
bigboateng merged 1 commit into
mainfrom
pypi-deployments
Apr 11, 2025
Merged

Add PyPI version checking to prevent duplicate version uploads#59
bigboateng merged 1 commit into
mainfrom
pypi-deployments

Conversation

@bigboateng

@bigboateng bigboateng commented Apr 11, 2025

Copy link
Copy Markdown
Collaborator

Important

Adds PyPI version checking to python-publish.yml to prevent duplicate version uploads by comparing and automatically bumping versions if necessary.

  • Version Checking:
    • Adds PyPI version check in python-publish.yml to prevent duplicate uploads.
    • Uses packaging module to compare NEW_VERSION with PYPI_VERSION.
    • Automatically bumps version if conflict detected.
  • Workflow Steps:
    • Installs packaging module in dependencies.
    • Checks if NEW_VERSION exists on PyPI before upload, exits if it does.
  • Misc:
    • Adds logging for version conflicts and actions taken.

This description was created by Ellipsis for 6a8cc8a. It will automatically update as commits are pushed.

@bigboateng
bigboateng merged commit cbca110 into main Apr 11, 2025
@bigboateng
bigboateng deleted the pypi-deployments branch April 11, 2025 20:56

@ellipsis-dev ellipsis-dev Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❌ Changes requested. Reviewed everything up to 6a8cc8a in 2 minutes and 16 seconds

More details
  • Looked at 54 lines of code in 1 files
  • Skipped 0 files when reviewing.
  • Skipped posting 9 drafted comments based on config settings.
1. .github/workflows/python-publish.yml:87
  • Draft comment:
    Bumping the version automatically based on PyPI data may mask configuration issues. It's risky to override the release process without explicit user confirmation.
  • Reason this comment was not posted:
    Comment did not seem useful. Confidence is useful = 0% <= threshold 50%
    This comment is about dependency version changes and suggests that the process might be risky. It doesn't provide a specific code suggestion or ask for a specific test to be written. It also doesn't point out a specific issue in the code. Therefore, it seems to violate the rules about commenting on dependency changes and asking for confirmations.
2. .github/workflows/python-publish.yml:172
  • Draft comment:
    Reusing 'pip install' to check if the specific version exists on PyPI might inadvertently install packages or misinterpret errors. Consider using 'pip index versions' for a consistent check.
  • Reason this comment was not posted:
    Comment looked like it was already resolved.
3. .github/workflows/python-publish.yml:172
  • Draft comment:
    The duplicate version existence checks (both before updating the version and during publishing) add unnecessary complexity. Consider consolidating the logic to one reliable check.
  • Reason this comment was not posted:
    Comment was on unchanged code.
4. .github/workflows/python-publish.yml:45
  • Draft comment:
    Added dependency 'packaging'. Consider pinning its version for reproducibility.
  • Reason this comment was not posted:
    Confidence changes required: 33% <= threshold 50%
    None
5. .github/workflows/python-publish.yml:82
  • Draft comment:
    Using 'pip install' with an invalid version to detect package existence is brittle. Consider a more robust method (e.g. pip index or PyPI JSON API).
  • Reason this comment was not posted:
    Marked as duplicate.
6. .github/workflows/python-publish.yml:84
  • Draft comment:
    Parsing pip index output via grep and sed is fragile and may break if output format changes.
  • Reason this comment was not posted:
    Comment did not seem useful. Confidence is useful = 20% <= threshold 50%
    This comment is informative and warns about potential fragility in the code due to parsing methods. However, it doesn't provide a specific suggestion or ask for a specific action to be taken. It doesn't align with the rules for good comments, which should be actionable or ask for confirmation of intent.
7. .github/workflows/python-publish.yml:88
  • Draft comment:
    Ensure the version comparison output has no extra whitespace that could affect the conditional check.
  • Reason this comment was not posted:
    Confidence changes required: 50% <= threshold 50%
    None
8. .github/workflows/python-publish.yml:92
  • Draft comment:
    Automatically bumping to the next patch version on conflict may override the intended release type. Verify this behavior is desired.
  • Reason this comment was not posted:
    Comment did not seem useful. Confidence is useful = 0% <= threshold 50%
    The comment is asking the PR author to verify if the behavior is desired, which is against the rules. It doesn't provide a specific suggestion or point out a clear issue with the code.
9. .github/workflows/python-publish.yml:173
  • Draft comment:
    Using 'pip install' to check for an existing version on PyPI can trigger side effects. Consider a read-only check (e.g. pip index or PyPI API) instead.
  • Reason this comment was not posted:
    Marked as duplicate.

Workflow ID: wflow_5024Iv9E3SoV4MvJ


Want Ellipsis to fix these issues? Tag @ellipsis-dev in a comment. You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.


# Check PyPI for existing versions
echo "Checking PyPI for existing package versions..."
if pip install browserstate==invalid_version 2>&1 | grep -q "browserstate"; then

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using 'pip install browserstate==invalid_version' to check if the package exists is brittle. Consider using 'pip index versions' or a dedicated API for more reliable behavior.

Suggested change
if pip install browserstate==invalid_version 2>&1 | grep -q "browserstate"; then
if pip index versions browserstate 2>&1 | grep -q "browserstate"; then

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant