Plan to transition to contrib-buster64
ocdtrekkie opened this issue · 5 comments
We should look to upgrading vagrant-spk's default VM to buster: https://app.vagrantup.com/debian/boxes/contrib-buster64
As part of this, we should attempt to make stacks less dependent on specific versions of Debian, so that the scripts are likely to run successfully even if the user wishes to change out the box used and upgrades for new releases are less painful so that we can encourage the use of the upgradevm command intended for inclusion with 1.0.
If we cannot avoid references to something like stretch-backports or the like, we may want to consider detecting the box version as part of the stack setup script and injecting the correct version.
Examples of where this might come up currently:
https://github.com/sandstorm-io/vagrant-spk/blob/master/stacks/lemp/setup.sh#L10
https://github.com/sandstorm-io/vagrant-spk/blob/master/stacks/golang/setup.sh#L11
We know that the basics of vagrant-spk at least work fine with Buster, because @cdubz has already done it: https://github.com/babybuddy/babybuddy-sandstorm (Fun side note, vagrant-spk upgradevm after the command is merged would actually downgrade this VM.)
For the record, I made this change because Django 3.x only supports Python 3.6+ while stretch has Python 3.5.x. Moving to buster seemed more straightforward than trying a backport of some sort. So this issue is important for future Django support (though Django 2.x is fine on Python 3.5).
I would 100% agree on that being the more straightforward way to go. :) Fundamentally vagrant-spk should mostly work on any jessie and up Debian flavor, as long as the contrib- box with vboxsf support is used. We want to move in the direction of pushing more recent code in Sandstorm packages in the future, so we want to "unstick" a lot of it.
Fixed by #291