diff options
Diffstat (limited to 'python-peru.spec')
| -rw-r--r-- | python-peru.spec | 549 |
1 files changed, 549 insertions, 0 deletions
diff --git a/python-peru.spec b/python-peru.spec new file mode 100644 index 0000000..a5e3f70 --- /dev/null +++ b/python-peru.spec @@ -0,0 +1,549 @@ +%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.nju.edu.cn/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 +* Mon May 15 2023 Python_Bot <Python_Bot@openeuler.org> - 1.3.1-1 +- Package Spec generated |