semvec/pypi-packages huggingface dataset:
drupy 0.8.4
Python based deployment tool for Drupal 7
Keywords: drupal, drupy, build

# 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.
tc-pysh 0.9.0
Some utils for file manipulation scripts

# Pysh

## About

Pysh aims at providing the tools required to write in Python the script I would have written in bash before.

Python provide a more robust, and more powerful environment for scripting and makes the script easier to maintain and extend.
Pysh makes it possible to write file manipulation script just as quickly as in bash.

It should be good both for quick one-of scripts, as well as more complex reusable small programs.

## Installation

Be careful: the `pysh` name was already taken on PyPI, it is a different package, that I have nothing to do with.
My package is named `tc-pysh`

```sh
pip install tc-pysh
```

## Usage

At the center of pysh is the path facilities: `tc_pysh.AbsolutePath` and `tc_pysh.RelativePath` are objects representing locations in the file system taht are easy to manipulate and use with pysh utils, as well as with most of python standard library thanks to `os.PathLike`.

`tc_pysh.utils` provides equivalents of the commonly used commands in bash scripts such as `mv`, `cp`, `rm`, `cat`, etc.

`tc_pysh.ls` and `tc_pysh.find` provides familiar interface to the `tc_pysh.query` facilities, making it easy to browse a directory or arborescence, with tools likes sorting and filtering in the form of iterators, building on top of the standard library and the `re` standard module.

`tc_pysh.file` provides a set of functions that are related to file *content*, like `grep`, `head` and `tail`.

Here is an example of using `ls` to print the sizes of all text files of a directory.
```python
from tc_pysh import ls
from tc_pysh.file import size, human

for f in ls().name(r".*\.txt").sort():
    s = size(f) 
    s, u = human(s)

    print(str(f), s, u)
```

Commands like `ls` return a `tc_pysh.stream.Stream` object, an iterable that
is designed to chain sequence operators such as `.map` and `.filter`.

`tc_pysh.script_utils` provide convenient wrappers around the builtin
`argparse` module that helps with generating CLI in a pythonic way.

```python
from tc_pysh import ls
from tc_pysh.file import size, human
from tc_pysh.script_utils import script, optional, positional


@script(
    positional("pat", help="Pattern to math against file names."),
    optional("root", default=".", help="Where to list files."),
)
def pls(opts):
    "List files matching PAT in ROOT."
    for f in ls(opts.root).name(opts.pat).sort():
        s = size(f)
        s, u = human(s)

        print(str(f), s, u + "B")


if __name__ == "__main__":
    pls()  # automatically parses sys.argv (but you can also explicitly pass the script)
```