github.com/go-gitea/gitea

Using Gitea as a Go package rather than a standalone application is challenging. The codebase is primarily designed as a monolithic application, not a library, which shows in the API surface. There's no clear separation between internal and public APIs, making it difficult to determine what's safe to import. Documentation for using Gitea programmatically is sparse - most docs assume you're running the server binary.

The package structure requires importing deep into internal modules, which creates fragile dependencies that break between minor versions. Type definitions are present but often buried in models packages with circular dependencies. Error handling is inconsistent, mixing string comparisons, error wrapping, and custom error types without clear patterns.

If you're embedding Gitea functionality or building tooling that interacts with a Gitea instance, you're better off using the SDK (gitea.com/sdk) or HTTP API directly. The main package works if you need deep integration, but expect to spend significant time navigating undocumented internals and handling breaking changes.

Gitea as a Go package presents challenges when you want to embed or extend it programmatically. While it's excellent as a standalone application, using it as a library requires navigating tightly-coupled internal packages. The codebase has improved its security posture over time, but you'll need to stay vigilant with updates as CVEs are discovered fairly regularly in a codebase of this complexity.

Authentication and authorization are well-architected with support for OAuth2, LDAP, and 2FA, but customizing these flows programmatically means diving deep into middleware chains that aren't always cleanly separated. Input validation is generally solid for Git operations, but edge cases in webhook handling and API endpoints have required patches. Error messages tend to be informative without leaking sensitive paths, though you'll want to audit any custom error handlers carefully.

The crypto defaults are reasonable (TLS 1.2+ by default), but you'll need to explicitly configure settings for production hardening. Database migration handling is well-structured, making upgrades manageable. The biggest friction comes from the lack of stable, documented APIs for embedding - most internal packages can change between minor versions.

Using Gitea as a Go package is challenging because it's primarily designed as a standalone application rather than a library. While you can import certain packages for specific functionality, there's minimal public API documentation for programmatic use. The codebase is well-structured internally, but many useful functions are buried in internal packages or tightly coupled to the application's architecture.

The type definitions are decent when you can access them, but IDE autocompletion struggles because of the deep package structure and frequent use of models that require database context. Error handling is inconsistent across different modules—some return wrapped errors with context, others return bare errors that require source diving to understand. Migration between versions can be painful as internal APIs shift without clear deprecation notices since they're not intended as public APIs.

If you're building tooling that needs to interact with Gitea, you're better off using the REST/API client approach rather than importing Gitea packages directly. The main value is in studying the codebase for implementation patterns or extending Gitea itself through forks.