Box not found during Vagrant up
edmorley opened this issue · comments
Using b9eb4f0 of this repo (latest master at time of posting), I get:
[~/src/django-box]$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Box 'django-box-1.11' could not be found. Attempting to find and install...
default: Box Provider: virtualbox
default: Box Version: >= 0
==> default: Box file was not detected as metadata. Adding it directly...
==> default: Adding box 'django-box-1.11' (v0) for provider: virtualbox
default: Downloading: django-box-1.11
default:
An error occurred while downloading the remote file. The error
message, if any, is reproduced below. Please fix this error and try
again.
Couldn't open file /C:/Users/Ed/src/django-box/django-box-1.11
==> default: VM not created. Moving on...
This occurs even if I uncomment the box_url pref in Vagrantfile.
It's worth noting that since a box URL isn't set, Vagrant will only look on https://atlas.hashicorp.com/boxes/search - where the box doesn't exist.
Hi @edmorley thanks for the report. This isn't quite ready for use, so the compiled version hasn't been uploaded to djangoproject yet. I still need to discuss with the rest of the core team whether or not we want to host the box on djangoproject or if we want to push to atlas.hashicorp.
I'll begin that discussion today and will link back here once that's done.
In the mean time you can build the box from scratch using the commands documented here: https://github.com/django/django-box#building-a-new-version
Ah that makes sense, thank you.
Out of curiosity, what's the reasoning for having a compiled box, rather than just the Vagrantfile-build as the main Vagrantfile?
The base box (bento/ubuntu-16.04) is going to be pretty common on developers' machines (at least once Xenial usage picks up), whereas the django compiled box is going to be a guaranteed 1.2GB download. My local Vagrant setup for Django (which I'd created prior to seeing this project) uses puppet and doesn't take long to build at all (though it does install less than this one), so not sure if there's a massive time saving.
If people having to install Ansible on the host machine is the problem, have you considered switching to the ansible_local provisioner instead?
Many thanks for working on this project - anything that makes it easier for people to contribute to Django will be a massive win! :-)
Honestly I hadn't thought much about whether or not we should provide a compiled box. It's simply the status quo - based on the setup of the original djangocore-box project a few years back. I'm open to changing it if we decide it makes sense. A few points for compilation though.
- The build takes about 20 minutes, including the final cleanup step which would be unnecessary without compilation. That's a fair amount of time to wait when spinning it up for the first time or doing
destroythenupfairly often. Have you published your own version anywhere? I wonder if we could reduce the build time in a meaningful way. - If there's a problem during build (network issues, package issues, etc) it's going to be harder for the average person to troubleshoot. Usually just running
vagrant provisionagain is enough but we'd also need to communicate that. - Advanced users that already use vagrant and have Xenial locally can rename the vagrant files and build their own box from scratch. They'd suffer the cleanup step if they don't edit it out, but the option remains.
- Versioning. If we make a small change and push out to atlas, then the next time users bring up the vm they'll be told about the update. There's less friction updating in this way rather than remembering to git pull periodically and rebuilding. Downside is that they'll have to download the full image again.
The tradeoffs here are really going to be build time/versioning vs bandwidth usage. I can download a 1.2gb box and have it running quicker than I can build from scratch. I know not all people have such luxuries though.
My version is just a rough hack locally so I could work on some PRs, it's not published :-)
Yeah very true about saving time for regular up/destroys. I think there is definitely value in the compiled box for many use-cases.
Versioning. If we make a small change and push out to atlas, then the next time users bring up the vm they'll be told about the update. There's less friction updating in this way rather than remembering to git pull periodically and rebuilding. Downside is that they'll have to download the full image again.
The ideal end state I see is that this project lives in the main django repo. That way (regardless of compiled box vs build locally) people just have to:
- git clone django repo
- install virtualbox/vagrant
- vagrant up
...with no added complication of having to clone a second repo and put it in the correct location.
In this scenario, even with the non-compiled approach, people will automatically get the newest Vagrantfile/box provisioning, as they update their django checkout as normal. The Vagrant config will even stay in sync with the Django version (ie one could checkout a Django LTS branch and the provisioned box would still work, even if there had been backwards incompatible dependency changes in the meantime).
The ideal end state I see is that this project lives in the main django repo. That way (regardless of compiled box vs build locally) people just have to
...with no added complication of having to clone a second repo and put it in the correct location.
That's an interesting proposition and one I hadn't considered. I don't mind this idea at all, but I think it's unlikely to happen, because it's yet another thing that must be brought up to date for every release. I'll mention it on the ML to see where the interest might be, and I'll include the idea in the DEP7 proposal.
because it's yet another thing that must be brought up to date for every release
I would see the Vagrantfile (et al) in release branches being something that isn't updated unless absolutely necessary - so there shouldn't be any additional work. ie: most people would just vagrant up from master.