deckhouse / deckhouse/deckhouse-cli

mirror: --exclude-module/--exclude-package ignore the @version part

Open
#425 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Go
Stars
20
Forks
7
Avg merge
3d 16h
Merged PRs (30d)
33

Description

Summary

--exclude-module <name>@<version> (and --exclude-package <name>@<version>) ignore the @version part. The documented format is module-name[@version], which implies version-level exclusion, but the whole module/package is excluded regardless of the version supplied.

Details

In blacklist mode Filter.Match matches by name only:

  • internal/mirror/modules/filter.goMatch checks f.modules[mod.Name]; the parsed version constraint is stored but never consulted.

The @version is still parsed at flag-processing time (so it must be a valid semver/constraint, otherwise the command errors), but it has no effect on what is excluded.

Packages reuse modules.Filter, so --exclude-package behaves the same way.

Impact

Silent over-exclusion. A user running --exclude-module foo@1.2.0 expecting to drop a single version actually drops all versions of foo, with no warning.

Expected

Either honor the version constraint in blacklist mode, or reject/document --exclude-module / --exclude-package as name-only.

As of main (62132d6a).

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in internal/mirror/modules/filter.go and trace Filter.Match from the mirror command's exclude-module and exclude-package flag handling. Check how parsed version constraints are stored and whether blacklist matching uses them. Done means version-specific exclusions behave as documented, or the name-only behavior is explicitly rejected or documented, with coverage for both module and package flags.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
cli
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.