Skip to content
Snippets Groups Projects

vagrant: Vagrantfile changes for ease of development

Closed Joseph Nuthalapati requested to merge njoseph/plinth:vagrant-dev-settings into master

Moved some frequently required operations to the Vagrantfile.

Newcomers to the project almost always face the issue of port 8000 not being available. Disabling system Plinth and running only the development version solves this issue.

Automatic upgrades are a frequent blocker for development and an unnecessary annoyance on a development setup.

Signed-off-by: Joseph Nuthalapati njoseph@thoughtworks.com

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • With this change, after running "vagrant up" and "vagrant provision", I get 503 Service Unavailable. How should plinth be started then?

  • I have seen new developers get confused between the Plinth deb package running inside the VM and the development version. I usually suggest them to stop and disable the system Plinth and run only their development version. This one step is a significant barrier to entry for Plinth development.

    The Vagrantfile is only for running the development version of Plinth, isn't it? Running the system Plinth on it isn't of any value. I'm thinking the developer workflow should be like this:

    $ vagrant up
    $ vagrant provision
    $ vagrant ssh
    $ sudo /vagrant/run --develop

    I want to document this as well and make it the recommended development work flow. I currently have to manually teach this to every developer who wants to contribute to the project for a short while.

    This merge request eliminates the additional steps of stopping the system Plinth to avoid port conflict, disabling it to avoid stopping it each time and also disabling unattended-upgrades as they are a constant hindrance during development blocking developers every time the box is destroyed and brought up.

    BTW, I think the step to restart plinth can also be removed.

  • @njoseph-guest Ok, we can try that. But we also need to update HACKING.md and the Vagrantfile's post_up_message.

  • Joseph Nuthalapati changed milestone to %0.37.0

    changed milestone to %0.37.0

  • added 3 commits

    • 1a7ffc91 - Update documentation about vagrant file changes
    • a19ad323 - vagrant: Remove plinth restart step
    • 21a0466d - vagrant: Single command to bring up the dev environment

    Compare with previous version

  • @jvalleroy-guest I have made more improvements.

    • Removed plinth restart step
    • vagrant up command on first run downloads, configures and runs Plinth in development mode
    • vagrant provision can be used to run Plinth on subsequent runs
    • Added documentation for doing all the above manually
    • Updated the post_up message
    • Added documentation on how to reset the application database

    The changes are in separate commits to make it easy to discard unwanted commits.

    Edited by Joseph Nuthalapati
  • @njoseph-guest I squashed and merged the first 3 commits.

    21a0466d causes a lot of problems for me:

    • "vagrant up" on freshly created box gets stuck in a loop waiting for package manager to be available.
    • Unable to cleanly exit, and leaves port 8080 in use even though no plinth process is running.
  • @jvalleroy-guest I suspected it to be risky and hence put it in a different commit. Let's ignore the last commit. It was over-engineering anyway.

Please register or sign in to reply
Loading