Using a newer version of azblob causes a compile error

[richardpark-msft]

We're using an older version of azblob (v0.6.0) but this can limit clients attempting to upgrade to newer versions of azblob.

azblob isn't GA yet, which means interface breaking changes are still possible, even if we do upgrade. The current compile error with 0.15.0 (latest as of this writing). It looks like it's just a simple expansion of arguments:

/storage.go:290:41: not enough arguments in call to blobURL.GetProperties
        have (context.Context, azblob.BlobAccessConditions)
        want (context.Context, azblob.BlobAccessConditions, azblob.ClientProvidedKeyOptions)
./storage.go:601:101: not enough arguments in call to blobURL.ToBlockBlobURL().Upload
        have (context.Context, *bytes.Reader, azblob.BlobHTTPHeaders, azblob.Metadata, azblob.BlobAccessConditions)
        want (context.Context, io.ReadSeeker, azblob.BlobHTTPHeaders, azblob.Metadata, azblob.BlobAccessConditions, azblob.AccessTierType, azblob.BlobTagsMap, azblob.ClientProvidedKeyOptions, azblob.ImmutabilityPolicyOptions)
./storage.go:625:104: not enough arguments in call to blobURL.ToBlockBlobURL().Upload
        have (context.Context, *bytes.Reader, azblob.BlobHTTPHeaders, azblob.Metadata, azblob.BlobAccessConditions)
        want (context.Context, io.ReadSeeker, azblob.BlobHTTPHeaders, azblob.Metadata, azblob.BlobAccessConditions, azblob.AccessTierType, azblob.BlobTagsMap, azblob.ClientProvidedKeyOptions, azblob.ImmutabilityPolicyOptions)
./storage.go:646:89: not enough arguments in call to blobURL.Download
        have (context.Context, number, number, azblob.BlobAccessConditions, bool)
        want (context.Context, int64, int64, azblob.BlobAccessConditions, bool, azblob.ClientProvidedKeyOptions)

We're discussing solutions, but filing the issue to track any discussion.

[richardpark-msft]

Attempt 1 - vendor a copy of azblob v0.6.0

This would decouple us from any changes to the azblob package, allowing us to use the unchanging subset of features from Azure Storage.

Unfortunately, this doesn't work. The problem is that the Event Hubs package exports a Credential interface that embeds azblob.Credential from the azblob package. That interface requires a private marker method:

// azblob.Credential
type Credential interface {
    pipeline.Factory
        // can't be implemented by someone external this package
    credentialMarker()
}

This is our normal use case:

// (azblob here is: "github.com/Azure/azure-storage-blob-go/azblob"

    cred, err := azblob.NewSharedKeyCredential("foo", "Zm9vCg==")

    leaser, err := NewStorageLeaserCheckpointer(cred, ts.AccountName, "someContainer", ts.Env)

Yields this compile error:

/storage.go:110:76: cannot use credential (variable of type Credential) as type "github.com/Azure/azure-event-hubs-go/v3/internal/azure-storage-blob-go/azblob".Credential in argument to azblobVendor.NewPipeline:
        Credential does not implement "github.com/Azure/azure-event-hubs-go/v3/internal/azure-storage-blob-go/azblob".Credential (missing credentialMarker method)

Which makes sense - a struct can't implement a private function that can be "seen" in a separate package.

[richardpark-msft]

Ah! I didn't go far enough - @jhendrixMSFT solved this by creating a pipeline from the new package, and passing that to the older package which works beautifully.