breaking(compute/pack): use package name from manifest

[Integralist]

The fastly compute deploy command expects the package file to be named the same as the name attribute in the fastly.toml manifest. The fastly compute pack command does not do this, it instead names the package file package.tar.gz and consequently this causes the deploy command to fail.

NOTE: It was probably assumed that if a user was using compute pack they might not be using the CLI for developing an application, so we shouldn't expect them to have a fastly.toml manifest present. In this PR we presume a manifest is present by default and fallback to using package.tar.gz otherwise.

[JakeChampion]

Note: I think this is a breaking change as it changes what the default output destination is for this command

[Integralist]

I would argue that because the existing behaviour doesn't work with fastly compute deploy (†) that this isn't a breaking change and is fixing broken behaviour.

† The reporter of the issue, an internal report, identified that the compute deploy command looks for the package to be named the same as the name field from the manifest (otherwise it returns an error).

@joeshaw would you concur or do you think this should be a new major release?

[joeshaw]

I don't have a strong opinion. To what extent do we consider the directory and package names to be exported API? Do external tools consume this that we're aware of? That's the thing that'd be the determining factor to me.

[JakeChampion]

Terraform configurations will need to be updated if they are relying on the default name -- https://github.com/JakeChampion/polyfill-service/blob/main/fastly/terraform/modules/service-compute/main.tf#L7

[Integralist]

OK so that's a fair point from @JakeChampion

We have no way to tell if there are Terraform users who have used the compute pack command to create a custom language Wasm binary (and clearly we do have users taking that approach, as Jake explained: the polyfill.io service is one of them) and so we'd have to publish a new major release if we want this CLI fix rolled out.

My concern is that this is a bug fix for the CLI, but we're inadvertently causing a breaking feature change for Terraform, and yet we need to roll out this bug fix for the CLI still. So avoiding a new major version release isn't possible in this case (correct me if I'm wrong and there are other ways to make this work).

I was going to say if we need to roll out a new major release, then at least we have a couple of other 'breaking' items in the pipeline that can be included in that release.

The only problem with that idea, is that both those breaking items aren't ready yet to be released (not any time soon at least).

Meaning: this PR would either have to wait until that next major release (which could be a long time) or we have to make two major releases (one now to fix the bug in the CLI, and another one later on down the line for these other items).

I'm going to chat internally with @pabergman about this.

[Integralist]

OK. I've spoken to Alexander and it sounds like this PR should be held off until we're ready to release a new major release (so I've marked this PR now as a 'breaking' change).

For @justinliew there is a workaround though. The compute deploy command provides a --package flag (docs) so that should let you point to a package generated by compute pack (e.g. compute deploy --package ./pkg/package.tar.gz).