From 8ae08742c836753c401dbd8242ea1345bd656a0f Mon Sep 17 00:00:00 2001 From: Roman Zimmermann Date: Fri, 16 Aug 2024 14:44:05 +0200 Subject: [PATCH] Switch to README.md --- README.md | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++ README.rst | 64 ------------------------------------------ pyproject.toml | 2 +- 3 files changed, 77 insertions(+), 65 deletions(-) create mode 100644 README.md delete mode 100644 README.rst diff --git a/README.md b/README.md new file mode 100644 index 0000000..e2e2ebb --- /dev/null +++ b/README.md @@ -0,0 +1,76 @@ +# drupy + +A multisite capable Drupal site-builder based on JSON-recipes. + +## Features + +- Download and extract packages, prepare a Drupal tree and run "drush + site-install" all from the same set of configuration files. +- Package lists and site-configurations are pure JSON (ie. easy + machine-generateable). +- configuration files can "include" other json-files (even remote + files). +- Built-in support for multisite installations (optimized for sharing + code in a manageable way). +- Install files from: git repositores, tarballs, local directories, + copy files, patches +- Fast: if you change only one project (ie. add a patch) only this + project is rebuilt. +- Use hashes to check the integrity of downloaded files. + +## Requirements + +- Python3 +- git +- drush (for running site-install) +- rsync +- A symlink capable file-system + +## FAQ + +- **Why not simply use drush make?** For our multi-site setup we'd + like a directory structure that looks something like: +``` +projects/ # packages + module1-7.x-1.0/ # code of module1 + module1-7.x-2.1/ # another version of module1 + somesite/ # code of the custom somesite projects + theproject/ # another custom project with a install_profile +htdocs/ # drupal-root + profiles/ + theproject/ -> ../../projects/theproject + minimal/ + standard/ + testing/ + + sites/ + somesite/ + modules/ # symlinks to projects in the projects sub-folder + contrib/ # only one copy of a module per version. + module1 -> ../../../../../projects/module1-7.x-1.0 + … + + themes/ + contrib/ + theme1 -> ../../../../../projects/theme1-7.x-1.0 + … + + othersite/ + modules/ + contrib/ # allow different versions of a module per site + module1 -> ../../../../../projects/module1-7.x-2.0 +``` + Directory layouts like this seems rather cumbersome with drush make + which seems to be a bit biased towards a one-drupal-tree-per-site + approach of hosting. + +- **Why not use sites/all/ for code-sharing?** sites/all/ doesn't + allow us to update modules site by site. If an module has an + update-hook (ie. brings down your site until drush updb is run) you + have to update the module-code. Then you need to run drush updb in + all sites to bring them online again. So the mean down-time for a + site is: n/2. With lots of sites this can take quite some time. + +- **Why care for code sharing at all?** Sharing the code for modules + means that our opcode cache needs to hold only one copy of a file + instead of one per site. diff --git a/README.rst b/README.rst deleted file mode 100644 index 2353d90..0000000 --- a/README.rst +++ /dev/null @@ -1,64 +0,0 @@ -drupy -===== - -A multisite capable Drupal site-builder based on JSON-recipes. - -Features --------- - -* Download and extract packages, prepare a Drupal tree and run "drush site-install" all from the same set of configuration files. -* Package lists and site-configurations are pure JSON (ie. easy machine-generateable). -* configuration files can "include" other json-files (even remote files). -* Built-in support for multisite installations (optimized for sharing code in a manageable way). -* Install files from: git repositores, tarballs, local directories, copy files, patches -* Fast: if you change only one project (ie. add a patch) only this project is rebuilt. -* Use hashes to check the integrity of downloaded files. - -Requirements ------------- - -* Python3 -* git -* drush (for running site-install) -* rsync -* A symlink capable file-system - -FAQ ---- - -* **Why not simply use drush make?** - For our multi-site setup we'd like a directory structure that looks something like: - - projects/ # packages - module1-7.x-1.0/ # code of module1 - module1-7.x-2.1/ # another version of module1 - somesite/ # code of the custom somesite projects - theproject/ # another custom project with a install_profile - htdocs/ # drupal-root - profiles/ - theproject/ -> ../../projects/theproject - minimal/ - standard/ - testing/ - sites/ - somesite/ - modules/ # symlinks to projects in the projects sub-folder - contrib/ # only one copy of a module per version. - module1 -> ../../../../../projects/module1-7.x-1.0 - … - themes/ - somesite-modules -> ../../../../projects/somesite/modules - contrib/ - theme1 -> ../../../../../projects/theme1-7.x-1.0 - … - othersite/ - modules/ - contrib/ # allow different versions of a module per site - module1 -> ../../../../../projects/module1-7.x-2.0 - - Directory layouts like this seems rather cumbersome with drush make which seems to be a bit biased towards a one-drupal-tree-per-site approach of hosting. - -* **Why not use sites/all/ for code-sharing?** - sites/all/ doesn't allow us to update modules site by site. If an module has an update-hook (ie. brings down your site until drush updb is run) you have to update the module-code. Then you need to run drush updb in all sites to bring them online again. So the mean down-time for a site is: n/2. With lots of sites this can take quite some time. -* **Why care for code sharing at all?** - Sharing the code for modules means that our opcode cache needs to hold only one copy of a file instead of one per site. diff --git a/pyproject.toml b/pyproject.toml index f078b84..f9fc11f 100644 --- a/pyproject.toml +++ b/pyproject.toml @@ -4,7 +4,7 @@ description = "Python based deployment tool for Drupal 7" authors = [ {name = "Roman Zimmermann", email="torotil@gmail.com"}, ] -readme="README.rst" +readme="README.md" dynamic = ["version"] dependencies = [ ]