fix: handle ~= and != version operators in Python dependency name parsing

[a-oren]

Summary

• Fix getDependencyName() to recognize ~ and ! as PEP 508 version operator characters, preventing them from being included in the package name (e.g. urllib3~=1.26.0 was parsed as package urllib3~ instead of urllib3)
• Replace the fragile three-index getFirstSign() approach with a simple loop over all PEP 508 operator characters (>, <, =, ~, !)
• Add unit tests for compatibility (~=) and exclusion (!=) operators, including combined extras + special operators

Implements TC-4041

Test plan

• All 358 existing unit tests pass
• New unit tests verify ~= and != parsing
• Manual CLI test with example requirements.txt from the ticket produces correct SBOM

🤖 Generated with Claude Code

Summary by Sourcery

Fix Python requirement parsing to correctly extract dependency names when PEP 508 version operators are present, and extend tests to cover these cases.

Bug Fixes:

• Correct dependency name extraction from Python requirement strings that include PEP 508 operators such as ~=, !=, >=, <=, >, and < so operator characters are not treated as part of the package name.

Enhancements:

• Simplify version operator detection in Python requirement parsing by scanning for any PEP 508 operator character instead of relying on multiple index lookups.

Tests:

• Add unit tests covering compatibility (~=) and exclusion (!=) operators, including cases combining extras with special version operators.

[sourcery-ai]

Reviewer's Guide

Updates Python dependency name parsing to correctly detect all PEP 508 version operator characters (including ~= and !=) and adds tests to cover these cases, especially when combined with extras and markers.

Class diagram for updated PythonControllerBase dependency parsing

classDiagram
  class PythonControllerBase {
    +static String getDependencyName(String dep)
    +static List~String~ splitPipShowLines(String pipShowOutput)
  }

Loading

File-Level Changes

Change	Details	Files
Generalize version operator detection in getDependencyName to handle all relevant PEP 508 operator characters instead of only >, <, and =.	Replace separate index lookups for '>', '<', and '=' with a loop that scans the requirement string for any of '>', '<', '=', '~', or '!' Use the first occurrence of a version operator character to slice the dependency name, defaulting to the whole requirement if none are found Remove the now-unnecessary helper method that computed the minimum index among the three operator positions	src/main/java/io/github/guacsec/trustifyda/utils/PythonControllerBase.java
Extend unit test coverage for getDependencyName to cover ~= and != operators and combinations with extras and markers.	Add tests ensuring compatibility (~=) and exclusion (!=) operators do not leak into the parsed package name Add tests verifying that extras combined with special version operators (including ~=) are parsed correctly Reuse existing test style and naming conventions to keep coverage focused on PEP 508 scenarios	src/test/java/io/github/guacsec/trustifyda/utils/PythonControllerRealEnvTest.java

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've reviewed your changes and they look great!

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[Strum355]

PR looks good for the changes mentioned. Looking at TC-4041, we also need to make sure that version extraction in splitToNameVersion also handles environment markers properly. Note the following error case mentioned in TC-4041:

# Expected: Install if condition is true, compare version "2.25.1" against manifest
# Java actual: Compares installed version "2.25.1" against "2.25.1 ; python_version >= '3.6'"
#             Results in version mismatch error even when versions match

idna==2.10 ; python_version >= "3.6"
six==1.16.0 ; python_version < "3.0" or python_version >= "3.3"
chardet==4.0.0 ; python_version >= "3.6" and sys_platform == "linux"

The environment markers are leaking here too when comparing the versions, so we need to correctly exclude markers in splitToNameVersion (according to Claude at least, thats the function responsible). I would be fine with including the fix for this in this PR.