Should We Expand Gitingest Support for Additional Git Hosts?

[filipchristiansen]

The recent PR #117 improved our domain-agnostic URL parsing and extended support from GitHub to include GitLab, Bitbucket, and Gitea. This enhancement was achieved by iteratively guessing the domain for a given user/repo, and supports the "URL trick".

In Issue #11, several other Git providers that we might consider supporting were suggested:

• codeberg.org/arpadbuermen/VACASK
• gitlab.winehq.org/wine/wine
• gitlab.gnome.org/World/Rust/poppler-rs
• salsa.debian.org/public
• cygwin.com/git.html
• savannah.gnu.org/git/?group=coreutils

Question for the Community:
Is expanding support to these (or other) Git providers a feature that would benefit you? If you have a use case that requires support for a specific Git host, please share the details and mention which host(s) you need.

Next Steps:
Until there's clear demand from the community, I propose we put this expansion on hold. However, if you know of additional Git hosts that could be valuable to support, let us know here.

Your feedback will help us prioritize new features based on actual user needs. Thank you!

[RyanL2004]

Regarding Issue #11, I’d like to suggest an approach for extending support to the additional Git providers not supported atm.

To simplify this process and make future expansions more efficient, I'd recommend exploring a modular approach for the URL parsing. By designing the parsing logic to dynamically handle new domains via configuration or plugins, the system can adapt more easily to support additional Git providers.

Here’s how it would work:

• Configuration-based system:
  Maintain a file (e.g., providers.json) where each Git provider’s domain and relevant parsing rules are defined.
  The URL parser would reference this configuration file, making it easy to add or update providers without modifying the core code.

• Plugin-based architecture:
  Create a system where each provider has its own module or plugin with specific parsing rules.
  The core parser dynamically loads the appropriate plugin based on the URL's domain.

Encourage community contributions, as adding new providers would only require creating a configuration entry or a plugin.

Future-proof the logic as swell, because it allows for seamless updates if Git providers change their URL patterns.

Here is some documentation that might help :

• Python Packaging User Guide
• Plugin Architecture YTB Video