If people want to do serious development on top of this Vagrantfile then I would recommend copying it into the root of their repo and using the /vagrant mount point to access their code. This approach has the advantage that your code lives outside the VM, so you can nuke the VM from orbit if anything goes wrong and you've not lost any code. The disadvantage is that the synced folder can be slow, and it doesn't always have the same behaviour as ext4, which might break some programs.
Alternatively, they could clone their repo inside the VM and use something like vscode-remote to get into it (use vagrant ssh-config >> ~/.ssh/config to add the host, so that vscode can find it). This approach has the disadvantage that you can't nuke the VM if something goes wrong, because it contains the source-of-truth copy of your code.
Either option is probably more convenient for prototyping than using the raspberry pi images.
In other news: I had some issues with the examples breaking when I unplug+replug the device (even though lsusb thinks everything is fine), so I've documented a workaround. It might just be me, but if this happens to people repeatedly then we can fix it as a separate issue.
As suggested in https://github.com/google-coral/project-posenet/pull/3#issuecomment-529705018 I have made a Vagrantfile that's suitable for putting in this repo.
This should address https://github.com/google-coral/edgetpu-platforms/issues/19
In terms of quality: I have tested it on my mac by building and destroying the VM a couple of times, and run the example on https://coral.withgoogle.com/docs/accelerator/get-started/#run-a-model-on-the-edge-tpu to make sure that everything works.
If people want to do serious development on top of this Vagrantfile then I would recommend copying it into the root of their repo and using the
/vagrantmount point to access their code. This approach has the advantage that your code lives outside the VM, so you can nuke the VM from orbit if anything goes wrong and you've not lost any code. The disadvantage is that the synced folder can be slow, and it doesn't always have the same behaviour as ext4, which might break some programs.Alternatively, they could clone their repo inside the VM and use something like vscode-remote to get into it (use
vagrant ssh-config >> ~/.ssh/configto add the host, so that vscode can find it). This approach has the disadvantage that you can't nuke the VM if something goes wrong, because it contains the source-of-truth copy of your code.Either option is probably more convenient for prototyping than using the raspberry pi images.
In other news: I had some issues with the examples breaking when I unplug+replug the device (even though lsusb thinks everything is fine), so I've documented a workaround. It might just be me, but if this happens to people repeatedly then we can fix it as a separate issue.