`golang-1-darwin` package is unused
Closed this issue · 10 comments
Feature Request
The golang-1-darwin package is unused and should either be used or, failing that, removed.
Detailed Description
We ostensibly import the golang-1-darwin for the iso9660wrap package, but don't actually use it to build the package.
Context
See the bosh-google-cpi-release for an example of importing and using both the golang-1-darwin and golang-1-linux packages. Although it should be noted that it seems strange to have the packaging script output two binaries and have the job select. I would have thought that it would be easier to have the packaging script select which binary to build and output, and then have the job just use whichever it gets.
Possible Implementation
- Use the
golang-1-darwinpackage to build a darwin version of theiso9660wrappackage. - Remove the
golang-1-darwinpackage.
Complexity
- Low - Simple enhancement or bug fix, no architectural changes or refactoring
- Medium - Change requires some thought, but is relatively isolated
- High - Significant architectural change or large refactor
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.
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.
Not stale.
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.
Not stale.
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?
🤯 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.
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.
Not stale.
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.