Add a Vagrant file to make it easier to install a development environment

[nickgarvey]

It's challenging to get to the stage where you can even get Eden running. The Wiki is a collection of assorted scripts and scattered instructions. This means people looking to contribute to this project have a large barrier to entry.

Luckily, the industry is converging on common software for this called vagrant. The idea is to write a specification file that configures the environment. For example, the file would say "start with a Debian stretch base image, install web2py, install other deps, update the eden config files, and start the server". This is then run inside of a virtual machine or other container, so anyone can develop regardless of their operating system.

A huge advantage of this method is that this makes it extremely easy to spin up a production instance as well. Instead of pointing this at a virtual machine, you would start on AWS instead. People in a crisis would be able to have this software up and running in an hour.

The proposal of this issue is to create a Vagrant config for Eden, and replace the existing Dockerfile in the repo with that Vagrant file. Once the Vagrant file is in place, Wikis will be updated to point to this, although old ones will be preserved for some time to ease the transition.

[nickgarvey]

@flavour - I'm planning on working on this, but I wanted to file this issue so you knew my intentions. What do you think? Anything I should keep in mind before I start?

If it looks good, please assign to me :)

[flavour]

You are totally fine to create a Vagrant install process & add a link to it, but I wouldn't replace the currently supported method until it proves itself.

[nursix]

I would be very very careful with statements like "people in a crisis would be able to have this software up and running in an hour" - it's kinda misleading about what Sahana is and does.

The recommendation is clearly to NOT try to set up a Sahana instance in a crisis situation - especially not with the expectation to have it up and running in an hour. That's not a software problem, but the wrong approach to crisis management solutions altogether.

For developers, I'm skeptical that a simpler setup will give us more contributions. Not even giving them a fully pre-installed dev environment has done that, so why would a tool?

Setting up a development environment is comparatively trivial, and typically, people who get stuck during the setup are hopelessly overcharged with understanding concepts and code, and (in the vast majority of cases) never make any useful contributions.

So, as far as I can tell from a decade of watching things - the productive contributor we're loosing due to our "high entry barrier" is a myth. Show me one.

[nickgarvey]

I would be very very careful with statements like "people in a crisis would be able to have this software up and running in an hour" - it's kinda misleading about what Sahana is and does.

Yup my mistake. The main goal here is to make it easier for people to contribute. Fast production deployments could be a fringe benefit that I won't publicize.

For developers, I'm skeptical that a simpler setup will give us more contributions. Not even giving them a fully pre-installed dev environment has done that, so why would a tool?

Fully pre-installed dev environment? Where is this?

Setting up a development environment is comparatively trivial

I don't think installing a Debian box, searching for a current Wiki page, and then running & debugging a bunch of shell scripts for old versions of Debian counts as trivial. A lot of programmers aren't very good at running systems but can still help write code. Let's enable them.

The productive contributor we're loosing due to our "high entry barrier" is a myth. Show me one.

I don't think it's possible to show you one. These are the people who say "oh this looks interesting, let me see if I can help", and turn away before even starting after they run into the huge bash scripts on the Wiki. They don't make any sounds, they just leave. We can't measure that.

Thanks a bunch for the input @nursix, it helped put this into perspective for me. I'll make sure this doesn't interrupt any existing flows so there isn't any downside (save my wasted time ;) ) if this isn't useful.

[nursix]

You don't actually need to install a Debian box for developing Sahana ;)

That's what I'm saying - the wiki gives you tons of extras which are "can", not must.

Musts are:

• Git
• Python-2.7 + pip
• python-lxml, python-dateutil (install with pip)

...and then clone web2py+PyDAL and Sahana inside apps. That's actually all you need to start developing Sahana.

All the rest covers special needs, e.g.

• VM for people who don't want to pollute their system (but a VM is /not/ required for Sahana development!)
• Debian box for people who don't want to develop under Windows (but you can very well develop Sahana under Windows!)
• a IDE for people who prefer one (but any simple programming editor would do!)
• more Python libraries if you want to test/develop certain functionality (but once you have pip, you can add them at any time)

...and so forth.

But the actual "entry barrier" is just the three points above, and that's a one-liner with apt-get (or zypper, in my case).

[stevenaldinger]

I've been working on this tonight and going to be sharing a solution as early as tomorrow. The current Dockerfile in the repo is based off of ubuntu 14.10 which is past end of life and no apt packages will install at this point so the docker build fails.
I have an updated Dockerfile that allows for a development environment on top of 14.04. I'll see about sharing a development dockerfile, production dockerfile, example docker-compose files for supported databases, and example kubernetes files for supported databases (as well as documentation for all... might take a few extra days to be thorough).

A decent amount of universities these days seem to encourage or require students to contribute to HFOSS projects. Even if they're not the most skilled developers or anything I think it'd be cool if it was more clear how to get them started and in addition we can make running this in production a non event for everyone.

No harm in making it even easier than it is now and I love devops-y projects anyway.

[flavour]

the ideal would be to have Docker be as thin a layer over our
mainline supported installation method as possible.
So:

• Debian Stable
• Download & Run bootstrap script:
  https://github.com/sahana/eden_deploy/blob/master/user-data.sh