`golang-1-darwin` package is unused about bosh-vsphere-cpi-release HOT 10 CLOSED

Should be "fixed" by de1553b.

The packaging script will now directly use the darwin package when doing a create-env on OSX.

This change was actually needed because the generic compile scripts in the golang-release no longer reach out and use a different packaged based on the detected platform.

from bosh-vsphere-cpi-release.

After chatting with Palermo, maybe instead we should actually use the platform in the packaging script to select between the golang-1-darwin package and the golang-1-linux package for building isowrap9660.

Updating the issue title and description accordingly.

from bosh-vsphere-cpi-release.

This issue was marked as Stale because it has been open for 21 days without any activity. If no activity takes place in the coming 7 days it will automatically be close. To prevent this from happening remove the Stale label or comment below.

from bosh-vsphere-cpi-release.

Not stale.

from bosh-vsphere-cpi-release.

This issue was marked as Stale because it has been open for 21 days without any activity. If no activity takes place in the coming 7 days it will automatically be close. To prevent this from happening remove the Stale label or comment below.

from bosh-vsphere-cpi-release.

Not stale.

from bosh-vsphere-cpi-release.

Well that's surprising. I was fully planning to just delete this package, because it's clearly not used by the packaging script here: https://github.com/cloudfoundry/bosh-vsphere-cpi-release/blob/master/packages/iso9660wrap/packaging#L4

But then I went and looked at what compile.env.generic actually does, and it totally doesn't use the path the script is in, but uses the platform you are on to assume where the golang package will live!
https://github.com/bosh-packages/golang-release/blob/master/src/1/compile.env.generic

So even though it's calling the script inside of the golang-1-linux package, it will setup the go environment for golang-1-darwin

🤯

This feels like a mistake in the bosh-packages scripts, but at the same time, it almost feels like a terrible feature. It makes the calling side look broken, but at the same time, now the calling side doesn't need to use uname to figure out the platform and call the correct script?

from bosh-vsphere-cpi-release.

🤯 That is wild!

I inherently don't like that it prevents the caller from selecting the golang package they want to use.. but I also can't think of a situation where the caller wouldn't want to just use the correct script for their platform.

from bosh-vsphere-cpi-release.

This issue was marked as Stale because it has been open for 21 days without any activity. If no activity takes place in the coming 7 days it will automatically be close. To prevent this from happening remove the Stale label or comment below.

from bosh-vsphere-cpi-release.

Not stale.

from bosh-vsphere-cpi-release.