Re: Dealing with circular dependencies
Hi,
...
> It goes like this for gh/dsoprea
> - d2
> |- github.com/dsoprea/go-exif
> |- github.com/dsoprea/go-logging
> |- github.com/dsoprea/go-utility
> |- back to go-exif
> |- github.com/dsoprea/go-png-image-structure
> |- github.com/dsoprea/go-exif
> |- <as above>
> |- github.com/dsoprea/go-logging
> |- github.com/dsoprea/go-utility
> |- back to go-exif
...
> Vendoring? I'm all ears.
...
In usql I uploaded 5 new Debian packages, but also vendored 5 ones as
listed at https://salsa.debian.org/go-team/packages/usql/-/tree/7785164aca76909d6eebc2162a9271f1c7c2de0d/debian/vendor.
If you look at usql as an example, keep in mind that
7785164aca76909d6eebc2162a9271f1c7c2de0d is the commit that was
uploaded but it is still pending in NEW queue so FTP Masters might
still object and demand that every single dependency is a separate Go
package.
The motivation for vendoring in usql was:
- Tiny dependencies by the same author (Ken Shaw) used almost only by
himself in his own project (usql) and very unlikely to be useful for
any other package.
- Tiny dependencies that are also outdated/unmaintained, and having
them as self-standing Debian packages could dangerously increase their
use when in fact we are waiting for usql to finally drop them
completely and be the last one using them.
- Tiny tiny dependencies that have no ITP or other indication that
they are needed elsewhere, and doing a separate package out of a 116
line Go file (https://github.com/yookoala/realpath/blob/master/realpath.go)
would be overkill.
I haven't investigated how popular these tools of dsoprea are, but it
might very well be the case that he is the only one using his own
libraries, and vendoring them all in one could make sense.
Reply to: