-
Notifications
You must be signed in to change notification settings - Fork 23
Box not found during Vagrant up #12
Comments
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 ( 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 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.
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. 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). |
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. |
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 |
Using b9eb4f0 of this repo (latest master at time of posting), I get:
This occurs even if I uncomment the
box_url
pref inVagrantfile
.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.
The text was updated successfully, but these errors were encountered: