path: root/python-peru.spec

%global _empty_manifest_terminate_build 0
Name:		python-peru
Version:	1.3.1
Release:	1
Summary:	A tool for fetching code
License:	MIT
URL:		https://github.com/buildinspace/peru
Source0:	https://mirrors.aliyun.com/pypi/web/packages/8e/c7/c451e70443c0b82440384d51f4b9517b921d4fe44172d63dc10a09da114f/peru-1.3.1.tar.gz
BuildArch:	noarch


%description
+++ b/peru.yaml
@@ -6,12 +6,14 @@ imports:
 git module dircolors:
     url: https://github.com/seebi/dircolors-solarized
     pick: dircolors.ansi-dark
+    rev: a5e130c642e45323a22226f331cb60fd37ce564f
 curl module pathogen:
     url: https://codeload.github.com/tpope/vim-pathogen/tar.gz/v2.3
     unpack: tar
     export: vim-pathogen-2.3/autoload/
+    sha1: 9c3fd6d9891bfe2cd3ed3ddc9ffe5f3fccb72b6a
 git module vim-solarized:
     url: https://github.com/altercation/vim-colors-solarized
-    rev: 7a7e5c8818d717084730133ed6b84a3ffc9d0447
+    rev: 528a59f26d12278698bb946f8fb82a63711eec21
```
Peru made three changes:
- The `dircolors` module, which didn't have a `rev` before, just got one. By
  default for `git`, this is the current `master` or `main`. To change that,
  you can set the `reup` field to the name of a different branch.
- The `pathogen` module got a `sha1` field. Unlike `git`, a `curl` module is
  plain old HTTP, so it's stuck downloading whatever file is at the `url`. But
  it will check this hash after the download is finished, and it will raise an
  error if there's a mismatch.
- The `vim-solarized` module had a hash before, but it's been updated. Again,
  the new value comes from `master` or `main` by default.
At this point, you'll probably want to make a new commit of `peru.yaml` to
record the version bumps. You can do this every so often to keep your plugins
up to date, and you'll always be able to reach old versions in your history.
## Commands
- `sync`
  - Pull in your imports. `sync` yells at you instead of overwriting existing
    or modified files. Use `--force`/`-f` to tell it you're serious.
- `clean`
  - Remove imported files. Same `--force`/`-f` flag as `sync`.
- `reup`
  - Update module fields with new revision information. For `git`, `hg`, and
    `svn`, this updates the `rev` field. For `curl`, this sets the `sha1`
    field. You can optionally give specific module names as arguments.
- `copy`
  - Make a copy of all the files in a module. Either specify a directory to put
    them in, or peru will create a temp dir for you. You can use this to see
    modules you don't normally import, or to play with different module/rule
    combinations (see "Rules" below).
- `override`
  - Replace the contents of a module with a local directory path, usually a
    clone you've made of the same repo. This lets you test changes to imported
    modules without needing to push your changes upstream or edit `peru.yaml`.
## Module Types
##### git, hg, svn
For cloning repos. These types all provide the same fields:
- `url`: required, any protocol supported by the underlying VCS
- `rev`: optional, the specific revision/branch/tag to fetch
- `reup`: optional, the branch/tag to get the latest rev from when running
  `peru reup`
The `git` type also supports setting `submodules: false` to skip
fetching git submodules. Otherwise they're included by default.
##### curl
For downloading a file from a URL. This type is powered by Pythons's standard
library, rather than an external program.
- `url`: required, any kind supported by `urllib` (HTTP, FTP, `file://`)
- `filename`: optional, overrides the default filename
- `sha1`: optional, checks that the downloaded file matches the checksum
- `unpack`: optional, `tar` or `zip`
Peru includes a few other types mostly for testing purposes. See `rsync` for an
example implemented in Bash.
## Creating New Module Types
Module type plugins are as-dumb-as-possible scripts that only know how to
sync, and optionally reup. Peru shells out to them and then handles most of
the caching magic itself, though plugins can also do their own caching as
appropriate.  For example, the git and hg plugins keep track of repos they
clone. Peru itself doesn't need to know how to do that. For all the details,
see [Architecture: Plugins](docs/architecture.md#plugins).
## Rules
Some fields (like `rev` and `unpack`) are specific to certain module
types. There are also fields you can use in any module, which modify the
tree of files after it's fetched. Some of these made an appearance in
the fancy example above:
- `copy`: A map or multimap of source and destination paths to copy.
  Works like `cp` on the command line, so if the destination is a
  directory, it'll preserve the source filename and copy into the
  destination directory.
- `move`: A map or multimap of source and destination paths to move.
  Similar to `copy` above, but removes the source.
- `drop`: A file or directory, or a list of files and directories, to
  remove from the module. Paths can contain `*` or `**` globs.
- `pick`: A file or directory, or a list of files and directories, to
  include in the module. Everything else is dropped. Paths can contain
  `*` or `**` globs.
- `executable`: A file or list of files to make executable, as if
  calling `chmod +x`. Also accepts globs.
- `export`: A subdirectory that peru should treat as the root of the
  module tree. Everything else is dropped, including parent directories.
Note that these fields always take effect in the order listed above, regardless
of the order they're given in `peru.yaml`. For example, a `move` is always
performed before a `pick`. Also note that these fields can't be given twice.
For example, instead of using two separate `move` fields (one of which would be
ignored), use a single `move` field containing multiple moves. In practice,
things work this way because these fields are parsed as keys in a dictionary,
which don't preserve ordering and can't repeat.
Besides using those fields in your modules, you can also use them in "named
rules", which let you transform one module in multiple ways. For example, say
you want the `asyncio` subdir from the Tulip project, but you also want the
license file somewhere else. Rather than defining the same module twice, you
can use one module and two named rules, like this:
```yaml
imports:
    tulip|asyncio: python/asyncio/
    tulip|license: licenses/
git module tulip:
    url: https://github.com/python/asyncio
rule asyncio:
    export: asyncio/
rule license:
    pick: COPYING
```
As in this example, named rules are declared a lot like modules and then
used in the `imports` list, with the syntax `module|rule`.  The `|`
operator there works kind of like a shell pipeline, so you can even do
twisted things like `module|rule1|rule2`, with each rule applying to the
output tree of the previous.
## Recursion
If you import a module that has a peru file of its own, peru can include
that module's imports along with it, similar to how git submodules
behave with `git clone --recursive`. To enable this, add `recursive:
true` in a module's definition.
It's also possible to directly import modules that are defined in the
`peru.yaml` file of another module. If your project defines a module
`foo`, and `foo` has a peru file in it that defines a module `bar`, you
can use `foo.bar` in your own imports. This works even if you never
actually import `foo`, and it does not require setting `recursive:
true`.
## Configuration
There are several flags and environment variables you can set, to
control where peru puts things. Flags always take precedence.
- `--file=<file>`: The path to your peru YAML file. By default peru
  looks for `peru.yaml` in the current directory or one of its parents.
  This setting tells peru to use a specific file. If set, `--sync-dir`
  must also be set.
- `--sync-dir=<dir>`: The path that all `imports` are interpreted
  relative to. That is, if you import a module to `./`, the contents of
  that module go directly in the sync dir. By default this is the
  directory containing your `peru.yaml` file. If set, `--file` must also
  be set.
- `--state-dir=<dir>`: The directory where peru stashes all of its state
  metadata, and also the parent of the cache dir. By default this is
  `.peru` inside the sync dir. You should not share this directory
  between two projects, or `peru sync` will get confused.
- `--cache-dir=<dir>` or `PERU_CACHE_DIR`: The directory where peru
  keeps everything it's fetched. If you have many projects fetching the
  same dependencies, you can use a shared cache dir to speed things up.
- `--file-basename=<name>`: Change the default peru file name (normally
  `peru.yaml`). As usual, peru will search the current directory and its
  parents for a file of that name, and it will use that file's parent
  dir as the sync dir. Incompatible with `--file`.
## Links
- [Discussion and announcements (Google
  Group)](https://groups.google.com/forum/#!forum/peru-tool)
- [Architecture doc](docs/architecture.md)
- [Using peru with make](docs/make_examples)

%package -n python3-peru
Summary:	A tool for fetching code
Provides:	python-peru
BuildRequires:	python3-devel
BuildRequires:	python3-setuptools
BuildRequires:	python3-pip
%description -n python3-peru
+++ b/peru.yaml
@@ -6,12 +6,14 @@ imports:
 git module dircolors:
     url: https://github.com/seebi/dircolors-solarized
     pick: dircolors.ansi-dark
+    rev: a5e130c642e45323a22226f331cb60fd37ce564f
 curl module pathogen:
     url: https://codeload.github.com/tpope/vim-pathogen/tar.gz/v2.3
     unpack: tar
     export: vim-pathogen-2.3/autoload/
+    sha1: 9c3fd6d9891bfe2cd3ed3ddc9ffe5f3fccb72b6a
 git module vim-solarized:
     url: https://github.com/altercation/vim-colors-solarized
-    rev: 7a7e5c8818d717084730133ed6b84a3ffc9d0447
+    rev: 528a59f26d12278698bb946f8fb82a63711eec21
```
Peru made three changes:
- The `dircolors` module, which didn't have a `rev` before, just got one. By
  default for `git`, this is the current `master` or `main`. To change that,
  you can set the `reup` field to the name of a different branch.
- The `pathogen` module got a `sha1` field. Unlike `git`, a `curl` module is
  plain old HTTP, so it's stuck downloading whatever file is at the `url`. But
  it will check this hash after the download is finished, and it will raise an
  error if there's a mismatch.
- The `vim-solarized` module had a hash before, but it's been updated. Again,
  the new value comes from `master` or `main` by default.
At this point, you'll probably want to make a new commit of `peru.yaml` to
record the version bumps. You can do this every so often to keep your plugins
up to date, and you'll always be able to reach old versions in your history.
## Commands
- `sync`
  - Pull in your imports. `sync` yells at you instead of overwriting existing
    or modified files. Use `--force`/`-f` to tell it you're serious.
- `clean`
  - Remove imported files. Same `--force`/`-f` flag as `sync`.
- `reup`
  - Update module fields with new revision information. For `git`, `hg`, and
    `svn`, this updates the `rev` field. For `curl`, this sets the `sha1`
    field. You can optionally give specific module names as arguments.
- `copy`
  - Make a copy of all the files in a module. Either specify a directory to put
    them in, or peru will create a temp dir for you. You can use this to see
    modules you don't normally import, or to play with different module/rule
    combinations (see "Rules" below).
- `override`
  - Replace the contents of a module with a local directory path, usually a
    clone you've made of the same repo. This lets you test changes to imported
    modules without needing to push your changes upstream or edit `peru.yaml`.
## Module Types
##### git, hg, svn
For cloning repos. These types all provide the same fields:
- `url`: required, any protocol supported by the underlying VCS
- `rev`: optional, the specific revision/branch/tag to fetch
- `reup`: optional, the branch/tag to get the latest rev from when running
  `peru reup`
The `git` type also supports setting `submodules: false` to skip
fetching git submodules. Otherwise they're included by default.
##### curl
For downloading a file from a URL. This type is powered by Pythons's standard
library, rather than an external program.
- `url`: required, any kind supported by `urllib` (HTTP, FTP, `file://`)
- `filename`: optional, overrides the default filename
- `sha1`: optional, checks that the downloaded file matches the checksum
- `unpack`: optional, `tar` or `zip`
Peru includes a few other types mostly for testing purposes. See `rsync` for an
example implemented in Bash.
## Creating New Module Types
Module type plugins are as-dumb-as-possible scripts that only know how to
sync, and optionally reup. Peru shells out to them and then handles most of
the caching magic itself, though plugins can also do their own caching as
appropriate.  For example, the git and hg plugins keep track of repos they
clone. Peru itself doesn't need to know how to do that. For all the details,
see [Architecture: Plugins](docs/architecture.md#plugins).
## Rules
Some fields (like `rev` and `unpack`) are specific to certain module
types. There are also fields you can use in any module, which modify the
tree of files after it's fetched. Some of these made an appearance in
the fancy example above:
- `copy`: A map or multimap of source and destination paths to copy.
  Works like `cp` on the command line, so if the destination is a
  directory, it'll preserve the source filename and copy into the
  destination directory.
- `move`: A map or multimap of source and destination paths to move.
  Similar to `copy` above, but removes the source.
- `drop`: A file or directory, or a list of files and directories, to
  remove from the module. Paths can contain `*` or `**` globs.
- `pick`: A file or directory, or a list of files and directories, to
  include in the module. Everything else is dropped. Paths can contain
  `*` or `**` globs.
- `executable`: A file or list of files to make executable, as if
  calling `chmod +x`. Also accepts globs.
- `export`: A subdirectory that peru should treat as the root of the
  module tree. Everything else is dropped, including parent directories.
Note that these fields always take effect in the order listed above, regardless
of the order they're given in `peru.yaml`. For example, a `move` is always
performed before a `pick`. Also note that these fields can't be given twice.
For example, instead of using two separate `move` fields (one of which would be
ignored), use a single `move` field containing multiple moves. In practice,
things work this way because these fields are parsed as keys in a dictionary,
which don't preserve ordering and can't repeat.
Besides using those fields in your modules, you can also use them in "named
rules", which let you transform one module in multiple ways. For example, say
you want the `asyncio` subdir from the Tulip project, but you also want the
license file somewhere else. Rather than defining the same module twice, you
can use one module and two named rules, like this:
```yaml
imports:
    tulip|asyncio: python/asyncio/
    tulip|license: licenses/
git module tulip:
    url: https://github.com/python/asyncio
rule asyncio:
    export: asyncio/
rule license:
    pick: COPYING
```
As in this example, named rules are declared a lot like modules and then
used in the `imports` list, with the syntax `module|rule`.  The `|`
operator there works kind of like a shell pipeline, so you can even do
twisted things like `module|rule1|rule2`, with each rule applying to the
output tree of the previous.
## Recursion
If you import a module that has a peru file of its own, peru can include
that module's imports along with it, similar to how git submodules
behave with `git clone --recursive`. To enable this, add `recursive:
true` in a module's definition.
It's also possible to directly import modules that are defined in the
`peru.yaml` file of another module. If your project defines a module
`foo`, and `foo` has a peru file in it that defines a module `bar`, you
can use `foo.bar` in your own imports. This works even if you never
actually import `foo`, and it does not require setting `recursive:
true`.
## Configuration
There are several flags and environment variables you can set, to
control where peru puts things. Flags always take precedence.
- `--file=<file>`: The path to your peru YAML file. By default peru
  looks for `peru.yaml` in the current directory or one of its parents.
  This setting tells peru to use a specific file. If set, `--sync-dir`
  must also be set.
- `--sync-dir=<dir>`: The path that all `imports` are interpreted
  relative to. That is, if you import a module to `./`, the contents of
  that module go directly in the sync dir. By default this is the
  directory containing your `peru.yaml` file. If set, `--file` must also
  be set.
- `--state-dir=<dir>`: The directory where peru stashes all of its state
  metadata, and also the parent of the cache dir. By default this is
  `.peru` inside the sync dir. You should not share this directory
  between two projects, or `peru sync` will get confused.
- `--cache-dir=<dir>` or `PERU_CACHE_DIR`: The directory where peru
  keeps everything it's fetched. If you have many projects fetching the
  same dependencies, you can use a shared cache dir to speed things up.
- `--file-basename=<name>`: Change the default peru file name (normally
  `peru.yaml`). As usual, peru will search the current directory and its
  parents for a file of that name, and it will use that file's parent
  dir as the sync dir. Incompatible with `--file`.
## Links
- [Discussion and announcements (Google
  Group)](https://groups.google.com/forum/#!forum/peru-tool)
- [Architecture doc](docs/architecture.md)
- [Using peru with make](docs/make_examples)

%package help
Summary:	Development documents and examples for peru
Provides:	python3-peru-doc
%description help
+++ b/peru.yaml
@@ -6,12 +6,14 @@ imports:
 git module dircolors:
     url: https://github.com/seebi/dircolors-solarized
     pick: dircolors.ansi-dark
+    rev: a5e130c642e45323a22226f331cb60fd37ce564f
 curl module pathogen:
     url: https://codeload.github.com/tpope/vim-pathogen/tar.gz/v2.3
     unpack: tar
     export: vim-pathogen-2.3/autoload/
+    sha1: 9c3fd6d9891bfe2cd3ed3ddc9ffe5f3fccb72b6a
 git module vim-solarized:
     url: https://github.com/altercation/vim-colors-solarized
-    rev: 7a7e5c8818d717084730133ed6b84a3ffc9d0447
+    rev: 528a59f26d12278698bb946f8fb82a63711eec21
```
Peru made three changes:
- The `dircolors` module, which didn't have a `rev` before, just got one. By
  default for `git`, this is the current `master` or `main`. To change that,
  you can set the `reup` field to the name of a different branch.
- The `pathogen` module got a `sha1` field. Unlike `git`, a `curl` module is
  plain old HTTP, so it's stuck downloading whatever file is at the `url`. But
  it will check this hash after the download is finished, and it will raise an
  error if there's a mismatch.
- The `vim-solarized` module had a hash before, but it's been updated. Again,
  the new value comes from `master` or `main` by default.
At this point, you'll probably want to make a new commit of `peru.yaml` to
record the version bumps. You can do this every so often to keep your plugins
up to date, and you'll always be able to reach old versions in your history.
## Commands
- `sync`
  - Pull in your imports. `sync` yells at you instead of overwriting existing
    or modified files. Use `--force`/`-f` to tell it you're serious.
- `clean`
  - Remove imported files. Same `--force`/`-f` flag as `sync`.
- `reup`
  - Update module fields with new revision information. For `git`, `hg`, and
    `svn`, this updates the `rev` field. For `curl`, this sets the `sha1`
    field. You can optionally give specific module names as arguments.
- `copy`
  - Make a copy of all the files in a module. Either specify a directory to put
    them in, or peru will create a temp dir for you. You can use this to see
    modules you don't normally import, or to play with different module/rule
    combinations (see "Rules" below).
- `override`
  - Replace the contents of a module with a local directory path, usually a
    clone you've made of the same repo. This lets you test changes to imported
    modules without needing to push your changes upstream or edit `peru.yaml`.
## Module Types
##### git, hg, svn
For cloning repos. These types all provide the same fields:
- `url`: required, any protocol supported by the underlying VCS
- `rev`: optional, the specific revision/branch/tag to fetch
- `reup`: optional, the branch/tag to get the latest rev from when running
  `peru reup`
The `git` type also supports setting `submodules: false` to skip
fetching git submodules. Otherwise they're included by default.
##### curl
For downloading a file from a URL. This type is powered by Pythons's standard
library, rather than an external program.
- `url`: required, any kind supported by `urllib` (HTTP, FTP, `file://`)
- `filename`: optional, overrides the default filename
- `sha1`: optional, checks that the downloaded file matches the checksum
- `unpack`: optional, `tar` or `zip`
Peru includes a few other types mostly for testing purposes. See `rsync` for an
example implemented in Bash.
## Creating New Module Types
Module type plugins are as-dumb-as-possible scripts that only know how to
sync, and optionally reup. Peru shells out to them and then handles most of
the caching magic itself, though plugins can also do their own caching as
appropriate.  For example, the git and hg plugins keep track of repos they
clone. Peru itself doesn't need to know how to do that. For all the details,
see [Architecture: Plugins](docs/architecture.md#plugins).
## Rules
Some fields (like `rev` and `unpack`) are specific to certain module
types. There are also fields you can use in any module, which modify the
tree of files after it's fetched. Some of these made an appearance in
the fancy example above:
- `copy`: A map or multimap of source and destination paths to copy.
  Works like `cp` on the command line, so if the destination is a
  directory, it'll preserve the source filename and copy into the
  destination directory.
- `move`: A map or multimap of source and destination paths to move.
  Similar to `copy` above, but removes the source.
- `drop`: A file or directory, or a list of files and directories, to
  remove from the module. Paths can contain `*` or `**` globs.
- `pick`: A file or directory, or a list of files and directories, to
  include in the module. Everything else is dropped. Paths can contain
  `*` or `**` globs.
- `executable`: A file or list of files to make executable, as if
  calling `chmod +x`. Also accepts globs.
- `export`: A subdirectory that peru should treat as the root of the
  module tree. Everything else is dropped, including parent directories.
Note that these fields always take effect in the order listed above, regardless
of the order they're given in `peru.yaml`. For example, a `move` is always
performed before a `pick`. Also note that these fields can't be given twice.
For example, instead of using two separate `move` fields (one of which would be
ignored), use a single `move` field containing multiple moves. In practice,
things work this way because these fields are parsed as keys in a dictionary,
which don't preserve ordering and can't repeat.
Besides using those fields in your modules, you can also use them in "named
rules", which let you transform one module in multiple ways. For example, say
you want the `asyncio` subdir from the Tulip project, but you also want the
license file somewhere else. Rather than defining the same module twice, you
can use one module and two named rules, like this:
```yaml
imports:
    tulip|asyncio: python/asyncio/
    tulip|license: licenses/
git module tulip:
    url: https://github.com/python/asyncio
rule asyncio:
    export: asyncio/
rule license:
    pick: COPYING
```
As in this example, named rules are declared a lot like modules and then
used in the `imports` list, with the syntax `module|rule`.  The `|`
operator there works kind of like a shell pipeline, so you can even do
twisted things like `module|rule1|rule2`, with each rule applying to the
output tree of the previous.
## Recursion
If you import a module that has a peru file of its own, peru can include
that module's imports along with it, similar to how git submodules
behave with `git clone --recursive`. To enable this, add `recursive:
true` in a module's definition.
It's also possible to directly import modules that are defined in the
`peru.yaml` file of another module. If your project defines a module
`foo`, and `foo` has a peru file in it that defines a module `bar`, you
can use `foo.bar` in your own imports. This works even if you never
actually import `foo`, and it does not require setting `recursive:
true`.
## Configuration
There are several flags and environment variables you can set, to
control where peru puts things. Flags always take precedence.
- `--file=<file>`: The path to your peru YAML file. By default peru
  looks for `peru.yaml` in the current directory or one of its parents.
  This setting tells peru to use a specific file. If set, `--sync-dir`
  must also be set.
- `--sync-dir=<dir>`: The path that all `imports` are interpreted
  relative to. That is, if you import a module to `./`, the contents of
  that module go directly in the sync dir. By default this is the
  directory containing your `peru.yaml` file. If set, `--file` must also
  be set.
- `--state-dir=<dir>`: The directory where peru stashes all of its state
  metadata, and also the parent of the cache dir. By default this is
  `.peru` inside the sync dir. You should not share this directory
  between two projects, or `peru sync` will get confused.
- `--cache-dir=<dir>` or `PERU_CACHE_DIR`: The directory where peru
  keeps everything it's fetched. If you have many projects fetching the
  same dependencies, you can use a shared cache dir to speed things up.
- `--file-basename=<name>`: Change the default peru file name (normally
  `peru.yaml`). As usual, peru will search the current directory and its
  parents for a file of that name, and it will use that file's parent
  dir as the sync dir. Incompatible with `--file`.
## Links
- [Discussion and announcements (Google
  Group)](https://groups.google.com/forum/#!forum/peru-tool)
- [Architecture doc](docs/architecture.md)
- [Using peru with make](docs/make_examples)

%prep
%autosetup -n peru-1.3.1

%build
%py3_build

%install
%py3_install
install -d -m755 %{buildroot}/%{_pkgdocdir}
if [ -d doc ]; then cp -arf doc %{buildroot}/%{_pkgdocdir}; fi
if [ -d docs ]; then cp -arf docs %{buildroot}/%{_pkgdocdir}; fi
if [ -d example ]; then cp -arf example %{buildroot}/%{_pkgdocdir}; fi
if [ -d examples ]; then cp -arf examples %{buildroot}/%{_pkgdocdir}; fi
pushd %{buildroot}
if [ -d usr/lib ]; then
	find usr/lib -type f -printf "\"/%h/%f\"\n" >> filelist.lst
fi
if [ -d usr/lib64 ]; then
	find usr/lib64 -type f -printf "\"/%h/%f\"\n" >> filelist.lst
fi
if [ -d usr/bin ]; then
	find usr/bin -type f -printf "\"/%h/%f\"\n" >> filelist.lst
fi
if [ -d usr/sbin ]; then
	find usr/sbin -type f -printf "\"/%h/%f\"\n" >> filelist.lst
fi
touch doclist.lst
if [ -d usr/share/man ]; then
	find usr/share/man -type f -printf "\"/%h/%f.gz\"\n" >> doclist.lst
fi
popd
mv %{buildroot}/filelist.lst .
mv %{buildroot}/doclist.lst .

%files -n python3-peru -f filelist.lst
%dir %{python3_sitelib}/*

%files help -f doclist.lst
%{_docdir}/*

%changelog
* Thu Jun 08 2023 Python_Bot <Python_Bot@openeuler.org> - 1.3.1-1
- Package Spec generated