I think it's time to invest in the automation of the initial setup of the development environment.
Here's what I do. I have a directory in which I clone every OpenWISP module, I install each module using: pip install -e . In my editor I open the main openwisp directory as a project so I can edit all the repositories at once. Each time there are new changes I pull from git, reinstalling via pip if needed: - pip install -U -e . Some modules, require extra dependencies, eg: - django-freeradius / openwisp-radius require cairo - openwisp-monitoring requires influxdb We could automate this. Automating the upgrade is useful and would give us a reason to keep using the tool so we can keep it up to date always. The procedure should be: - create a virtualenv using python 3.6 or higher, return error if no python 3.6 available on the system, if virtualenv already exists skip - clone each openwisp module, starting from the base dependencies, openwisp-utils, netjsonconfig, netdiff, django-x509, etc, if repo is already cloned, pull from the current branch (eg: git pull, this would allow us to change branches in development) - install any required system package (eg: cairo, influxdb, sqlite), we may as well add these system packages in the repositories somehow - install the python package with pip install -U -e . - if it's a django package, cd into tests/ and run ./manage migrate, then check whether there's a superuser in the DB, and if not, create one with username/password admin/admin I'd initially aim to support only linux distributions like Debian, Ubuntu, Fedora. We may implement this as a bash script in openwisp-utils, or something else like ansible. Having it in openwisp-utils would have the advantage of being integrated with the rest of the best practices we're introducing, so one would have to clone and install only openwisp-utils manually, then openwisp-utils does the rest. The disadvantage is that it may be cumbersome to support both Debian and Fedora, but I think the differences are just in the package manager and package names, that can be easily resolved. Then we'd just have to document this feature in https://github.com/openwisp/openwisp2-docs/ Providing suggestions regarding forks and things like that. For forks, I'd suggest to add it as a remote named "fork", and suggest to always set development branches to track the fork branch, so that "git pull" will work without problems when upgrading. This should help new contributors getting up to speed very quickly. Let me know what you think. Federico -- You received this message because you are subscribed to the Google Groups "OpenWISP" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web, visit https://groups.google.com/d/msgid/openwisp/CAERYH6UEve2d5%2BuD5qVNZQw%3DxDTQOLK1PnbBWXB3tQhRhiv9jA%40mail.gmail.com.
