Open halostatue opened 5 months ago
go2port uses its own very simple package-resolving logic (I don't know where the "real" logic is or whether it's reusable in an application like go2port). This logic can't handle submodule dependencies correctly.
For instance cloud.google.com/go/kms
and cloud.google.com/go/compute/metadata
both resolve to submodules in github.com/googleapis/google-cloud-go
, but currently in MacPorts (via the golang-1.0 portgroup) both modules can only be manifested by a single revision of their containing repo.
This means that if the project wants versions of cloud.google.com/go/kms
and cloud.google.com/go/compute/metadata
that correspond to different commits in the repo, then you will get the "wrong" version for (at least) one of them. This essentially means that you aren't guaranteed to build your port from the right set of source files.
Sometimes you'll get lucky and everything will work fine. Some ports are built like this and seem to work fine, or maybe they're subtly buggy but no one has noticed.
So if you like to gamble like this, the trick to getting the portfile to work is:
cloud.google.com/go/*
entries from go.vendors
and leave just cloud.google.com/go
(which happens to be there already; if it wasn't you'd need to add it manually).github.com/aws/aws-sdk-go-v2/*
(github.com/aws/aws-sdk-go-v2
is already included, so no extra work needed)github.com/hashicorp/go-secure-stdlib/*
, but here github.com/hashicorp/go-secure-stdlib
is not included so that needs to be added manually. Poking around the tags for the specified submodules, I found that the tag v0.1.0 happens to represent the correct version for all three.google.golang.org/protobuf
is hosted on go.googlesource.com, which can't serve stable tarballs, so that needs to be manually resolved to the GitHub mirror. I will add a special case to go2port to handle this because it's such a common dependency.Thus you can see that go2port is really a hack that only works well when a project happens to have well-behaved dependencies. I'm sure it could be improved by someone who has better knowledge of golang dependency resolution, but that's not me.
The MacPorts project as a policy strongly discourages downloading dependencies at build time, but there are some golang ports that do so because getting the golang-1.0 portgroup and go2port to work for them is so cumbersome.
If you do want to go with go2port, I have manually applied the above fixes:
Also I should note that I already released an update to go2port that has some changes that make things a little bit easier to diagnose:
size 14
, unresolvable dependencies will be size 0
(also checksums will be 0)Thank you for your response and the updated release. I’ll look at it more in depth this evening, but your explanation makes sense.
So, I finally had a chance to try this. The resulting portfile still doesn't work — but that's because I think there's something fundamentally broken about the golang portgroup. The tags for the AWS tree files are specific to the sub-SDK being looked at — for STS, it should be trying to download service/sts/v1.17.6
, but it is trying to download service/v1.17.6
.
I spent a bit of time reading trac:61192 and then looking at what go mod vendor
and go mod download
do … and I don't see a clean way around this without lifting about ~30% of what go mod
subcommands do. It would be nice if Go made the code behind the go mod
subcommands available as library functions. Barring that and/or interest in someone hosting that code into something that go2port
or other tools could use, I suspect that the best choice for MacPorts would be to run builds pointing to its own module proxy, something like athens in sync
or async_redirect
download mode.
The next best choice would be to have maintainers run go mod vendor
and tar up the resulting vendor directory and make that available somehow to the distfiles server. That "somehow" carries a lot of weight, especially since there would be a security risk involved.
I ran
go2port update please v17.6.2 --output Portfile
and things looked good, butsudo port install
fails because of 404s on archives.This doesn't entirely make sense for the initial failure (
aws-aws-sdk-go-v2-service-v1.17.6.tar.gz
), which is added togo.vendors
as:However, there are 26 entries in
go.vendors
which result insize 14
and identicalrmd160
/sha256
blocks, because it's all404 Not Found
.I'm not sure if these issues are related, but something feels off, regardless, and I’m not sure where to begin.
I'm attaching the updated/generated
Portfile
for reference.