I can’t imagine the painful amount of work that went into the setup scripts for Pi and for desktop Debian Jessie. Let me thank those intrepid souls who came before me who blazed the trail for getting Zynthian to be something someone can just set up in a VM on their rainy Sunday afternoon.
I’m curious if anyone has seen or heard of vagrant (link above)? The idea is to have the setup for your development environment be uniform from person to person, have it run in a VM for developers convenience and to have it be 1-2 commands to get started.
I’m experienced in vagrant and would be willing to try to get a project off the ground that does Zynthian dev in a virtual box VM using vagrant.
You are completely right. Generating the Zynthian Gorgona images/scripts has been a very hard task. I sweat while thinking about it!
We really need to improve our development platform, and perhaps Vagrant and other similar tools can help with it. The perfect world would be a development environment, PC-based, capable of running the full stack of Zynthian software and cross-compile and generate Zynthian images for the different platforms:
RaspBerry Pi 3
RaspBerry Pi 2
If you have experience with Vagrant and think that it can be useful, please feel free to experiment with it and give feedback. I’m really interested in it, but currently i’m completely focussed in software development and community management, and believe me, this 2 tasks eats all my time …
Anyway, in the next weeks/months we will release a new Zynthian image and it would be amazing to have a better system for the task, so yes, any work in this direction would be really welcome.
So so awesomely excited about the advertised next release, @jofemodo!
I found this with some bit of digging… before I gave up and whipped out my RPi, I was trying to work with Zynthian on a Debian VM using VirtualBox on my Mac. The above link probably would have saved me some time… If it closely resembles an RPi environment (I’m thinking, what about x86_64 vs. ARMF and so on?), then it’s seriously worth some consideration. It’d be a good way to allow folks to quickly try Zynthian without committing to an expensive HW build. I know we have the emuface, and it works great, but we also need the environment surrounding the emuface…?
As far as continuous integration/Travis–I found this fella, who is trying to do a Travis build on a Raspberry Pi. Check out this blog post since it seems to get us very, very close!
At work we’ve tended to not use vagrant so much since we used pyenv, which has addressed some of the problems with virtualenvwrapper, especially when dancing back and forward between python 2 & 3.
. . . In fact my only use of vagrant (& virtualbox) at the moment is to allow me to run a windows vm to test the strange idiosyncrasies of Microsoft browsers in relation to our websites and skyped meetings which are all under Windows Domains.
That’s not to say it’s not a wonderful tool and shared directories is a wonderful aspect of it, which vagrant will manage VERY nicely ( I have configured vm’s without vagrant and it can be a little ‘involved’ especially networking).
If you are trying to develop that way, you really need something like pycharm to allow debugging on the vm from your host, and if you are hosting on windows expect to spend a lot of time puzzling over directory name mappings.
So I’m a huge fan of pyenv just for the record. Virtualenvwrapper never seemed to work exactly right for me. I guess my idea here is more around the HW itself. A lot of the Zynthian code is actually about building/managing the image that will be dumped onto your flash card. Things like disabling rpi-updates, which you’d want for your Zynthian machine. It’s hard to test that unless you have the environment (that is, a Pi), and there are other instances where even having a Pi isn’t enough because 1) you may want to use your Pi for something else for the moment, and 2) you may have the Pi but not have the DAC.
So Vagrant would be a very slick option in this case. We’d have to figure out some other HW emulation for things like the DAC, but you could at least test the integration of the whole system image.
