I've been willing to do this for a while and last night I was bitten by an issue that would be easily diagnosed if I knew from where the box was downloaded. Basically the URL written on the Vagrantfile was different from the one I downloaded but both boxes had the same name :(
The newly added StateFile class can be improved but as usual, I think this is a good start :)
I like the general idea. I think instead of a dedicated state file, we should just put a state file into each box directory. This will be easier to keep track of because then the whole directory can just be removed when removing the box.
I think this should target Vagrant 1.4 due to the magnitude of the change.
I'm not convinced yet of the "-i" option when listing boxes. I think maybe we should just show it as part of vagrant box list. I want to get machine-readable into 1.4 so if people are trying to script Vagrant they can just get machine readable output out of vagrant box list
vagrant box list
Cool, I'll update the PR accordingly :)
Regarding the "-i" option, I just think that if we are going to always show that information we might need to change the output as it is very verbose in my option. If you can think of a better way to present that just LMK :)
Just to double check, what do you think about adding those new actions / middlewares? Am I on the right track?
As a note to myself, we'll need to make sure the dedicated state file gets skipped when repackaging boxes with vagrant package as it won't make sense to include them on the .box package. I'm not sure if Vagrant automatically packages the whole dir or not but might be worth checking it out.
Oh, and I agree to target 1.4 and I have just tagged this on the 1.4 GitHub milestone ;)
@mitchellh I've updated the branch with the changes we discussed over IRC but I kept the -i option for now. Please LMK if you think I should just drop it or if you think we can change the output to be less verbose in some way :)
I don't really like the extra_info on method names but unfortunately I'm out of ideas on how to name those methods. If you have a better idea just LMK
core: Pass on the newly added box to the rest of the middleware stack
core: Scaffold an action for persisting box information
commands/box: Introduce a StateFile for keeping track of downloaded b…
core: Write box information after download
commands/box: Extract box removal code from `box remove` command into…
… a builtin action
core: Remove box information from state file after box removal
commands/box: Extract a base class for dealing with StateFile instant…
commands/box: Preparing to display additional box information on `box…
commands/box: List base box downloaded URL and datetime when `-i` get…
…s provided to `box list`
core: Improve RemoveBoxInfo and WriteBoxInfo docs a bit
core: Get rid of code that deals with box info on a separate statefile
core: Persist box URL and download date into a JSON file under boxes …
commands/box: Read box URL and downloaded date from JSON
Thanks @fgrehm. I'm going to get this in today. I'm going to make some minor changes but the core functionality is great.
🎆 awesome! 🎆