* Added app dependencies resolving using `required_apps`
* Simplified workflow + docstring to explain what's goin on xD
* Get rid of redundant restart_bench kwarg from get_app
Why bother creating a bench well in advance? If someone wants to install
your app, they should be able to with a single command.
For instance, you can run simply `bench get healthcare` in any directory and bench will be setup automatically
* Less messier way of setting up and managing pre-fetched app meta
* Added support to fetch apps using the GitHub org/repo pattern
* Can be used to get apps and easily handle dependencies through version
identifiers
* Replaced one of the = with ~ to allow any patch releases to be
compatible
* Removed pinning from requests, honcho & Click since we're using the
more basic APIs
* Made these changes so that it's easier to install bench globally :')
* chore: typo
* chore: update project description
* feat: command to install dev-requirements.txt
Often applications have development or test specific requirements which
are not required in production.
- Add new command `bench setup dev-requirements`
- installs all `dev-requirements.txt` in app's root folder.
* refactor: remove duplicate function
* refactor: use `log` instead of print
* refactor: merge dev-requirement command
* feat: install dev-dependencies in get-app if dev
When developer mode is enabled install all dev dependencies too while
doing `get-app`
* fix: warn about --dev not supporting node
* feat: set default version for easy install to v13
* fix: python version based version picking fixed and reverted changes to node version in installation script
* fix: revert test version
Co-authored-by: gavin <gavin18d@gmail.com>
These changes are valid only for Py3.6+ and will remove bench CLI
support for Python 3.5 and lesser.
* Converted to f-strings using flynt
* Manual conversion of failed cases
* Simplification of logic
If an unshallow clone has to be updated, the only way to update it
without a reset will require an unshallow. This is because there may be
uncommitted or committed changes in any of the apps, although unfavoured
should be handled safely. The only way to update such repos is via the
user configured settings..or a ff only merge.
Biggest bottleneck is in the validation stage which checks if the app is
installed on any existing sites on the bench. instead of triggering
multiple list-apps for each sites, do one for all.