Re: Dealing with circular dependencies
On 28/08/2025 18:50, Otto Kekäläinen wrote:
Hi!
1. github.com/dsoprea/go-utility - This one declares #2 in go.mod
2. github.com/dsoprea/go-exif - This one doesn't declare #1 in go.mod,
What is your end goal, is there a third package that depend on these?
Trying to package d2 (github.com/terrastruct/d2) and thought I had
dependency hell under control when I did a first pass to check what was
missing.
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
And I still haven't compiled go-png-image-structure to find out if
anything hidden is imported directly.
Are other Go packages likely to depend on these? One option would be
to simply vendor these two tiny adn rarely updated dependencies in the
main package that is your goal, or just package go-utility and vendor
go-exif inside it.
Vendoring? I'm all ears.
You're right about the fact that the utilities are rarely updated. While
go-exif is tagged/versioned and has a command line program, it's not at
the level of exiftool and much more about the exif blob itself. Not
essential to package the program.
So put the 4 packages above into d2 then?
Do you have a simple example of vendoring? usql?
Can I invent a golang-github-dsoprea-dev package and vendor everything
gh/dsoprea inside? orig tarball would be empty. Or this too far?
--
Regards,
Ahmad
Reply to: