search

jorisroovers / gitlint

Linting for your git commit messages
http://jorisroovers.github.io/gitlint
MIT License
787 stars 99 forks source link

gitlint or gitlint-core? #551

Closed tucked closed 1 week ago

tucked commented 1 week ago 
$ pipx install gitlint
Note: Dependent package 'gitlint-core' contains 1 apps
  - gitlint

No apps associated with package gitlint. Try again with '--include-deps' to include apps of dependent packages, which are listed above. If you are attempting to install a library, pipx should not be used. Consider using pip or a similar tool
instead.

Should I be installing gitlint-core instead? What is the difference?

sigmavirus24 commented 1 week ago

https://github.com/jorisroovers/gitlint/pull/246

I believe the concern was that if pins were relaxed for gitlint then there would be a problem. So gitlint retains the pins and depends on gitlint-core[trusted-deps]. pipx is relying solely on the metadata of gitlint but gitlint is basically just an alias now to gitlint-core which defines the gitlint binary.

tucked commented 1 week ago

If gitlint is the CLI (application i.e. strict pins) and gitlint-core is the API (library i.e. flexible pins), shouldn't the CLI be bundled with gitlint instead of gitlint-core?

sigmavirus24 commented 1 week ago

Where did I (or anyone for that matter) say that gitlint-core was the API library? Please, invest some small amount of time in reading the linked threads (there are others linked from the PR). One such motivating comment is this one.

tucked commented 1 week ago

Sorry, I see now gitlint is just an alias for gitlint-core[trusted-deps] and should be avoided.

sigmavirus24 commented 1 week ago

If you want to avoid it, you may do so. There's no need to avoid it. But you're tenor is unproductive, so I'm unsurprised you're jumping to incorrect conclusions and making bold and incorrect statements

tucked commented 1 week ago

Please forgive the tenor. I've had this discussion many times...

The architecture that has been chosen

  1. is uncommon and undocumented.
  2. kinda breaks a key use case (Installing stand alone command line tools).
  3. seems to be in place because the maintainers are afraid of breakage (which is generally unavoidable, as Sorin explains) at the expense of downstreams being able to work around breakages without intervention from gitlint devs (e.g. imagine if a CVE was found in trusted-deps).

Personal style, of course, but I also don't love issues being closed before they're resolved (especially when I can't reopen them), and this issue definitely isn't resolved IMO, since we could use it as a prompt to improve the documentation, improve the pipx experience, revisit the architecture since some time has passed and a new data point has been raised, etc.