diff options
| author | CoprDistGit <infra@openeuler.org> | 2023-05-15 09:23:27 +0000 |
|---|---|---|
| committer | CoprDistGit <infra@openeuler.org> | 2023-05-15 09:23:27 +0000 |
| commit | 36129352cd266bc4d0afbd61685378d41832e305 (patch) | |
| tree | b83a8fe35c5948efd5a2537772b1e847c53320d0 | |
| parent | deee8db071dde9ad4dfe18e0a1ffb9e36f8e8990 (diff) | |
automatic import of python-cpenv
| -rw-r--r-- | .gitignore | 1 | ||||
| -rw-r--r-- | python-cpenv.spec | 657 | ||||
| -rw-r--r-- | sources | 1 |
3 files changed, 659 insertions, 0 deletions
@@ -0,0 +1 @@ +/cpenv-0.5.34.tar.gz diff --git a/python-cpenv.spec b/python-cpenv.spec new file mode 100644 index 0000000..e279cac --- /dev/null +++ b/python-cpenv.spec @@ -0,0 +1,657 @@ +%global _empty_manifest_terminate_build 0 +Name: python-cpenv +Version: 0.5.34 +Release: 1 +Summary: Cross-platform module and environment management. +License: MIT +URL: https://pypi.org/project/cpenv/ +Source0: https://mirrors.nju.edu.cn/pypi/web/packages/28/67/c4825e79ddfb3cf6e1a66abab68ecebf85b501881f1e2d5bcd863422c398/cpenv-0.5.34.tar.gz +BuildArch: noarch + +Requires: python3-tqdm +Requires: python3-colorama +Requires: python3-psutil + +%description +<p align="center"> + <img src="https://raw.github.com/cpenv/cpenv/master/res/icon_dark.png"/> +</p> + +# cpenv +Manage software plugins, project dependencies and environment +variables using Modules. + +<p align="center"> + <img src="https://raw.github.com/cpenv/cpenv/master/res/demo.gif"/> +</p> + +# Installation +The recommended method of installing cpenv is via [pipx](https://pipxproject.github.io/pipx). +Pipx is used to install python cli applications in isolation. + +``` +pipx install cpenv +``` +``` +pipx upgrade cpenv +``` +``` +pipx uninstall cpenv +``` + +# Overview +Cpenv is a cli tool and python library used to create, edit, publish, and activate Modules. A Module is a folder containing a dependency, like Arnold for Maya, and a module file that configures it. + +## Environment Variables +| Variable | Description | Default | +| ------------------------ | -------------------------------------- | ------- | +| CPENV_HOME | Customize path to cpenv home | | +| CPENV_DISABLE_PROMPT | Disable prompt when modules activated | 0 | +| CPENV_ACTIVE_MODULES | List of activated modules | | +| CPENV_SHELL | Preferred subshell like "powershell" | | + +## Example Modules +- [snack](https://github.com/cpenv/snack) + +## Create a Module +Use `cpenv create <module>` to use a guide to create a new Module. +This will create a new folder in your current working directory with a module file in it. + +## Edit a Module +Each Module contains a module.yml file, referred to as a module file. A module file contains metadata like the name and version of a module, as well as configuration, like environment variables. +``` +# Variables +# $MODULE - path to this module +# $PLATFORM - platform name (win, mac, linux) +# $PYVER - python version (2.7, 3.6...) + +# Wrap variables in brackets when they are nested within a string. +# DO 'this${variable}isnested/' NOT 'this$variableisnested' + +name: 'my_module' +version: '0.1.0' +description: 'My first module.' +author: 'Me' +email: 'me@email.com' +requires: [] +environment: + MY_MODULE_VAR: 'Test' +``` + +### Environment key +Setting a value will insert a key or overwrite it's existing value. +``` +SOME_VAR: 'SOME_VALUE' +``` + +Use the $MODULE variable for module relative paths. +``` +RELATIVE_VAR: $MODULE/bin +``` + +Use lists to prepend values to a key. +``` +PATH: + - $MODULE/bin +``` + +Use `win`, `linux` and `mac or osx` keys to declare platform specific values. If you leave out a platform, the variable will not be included on that platform. +``` +PLATFORM_VAR: + mac: /mnt/some/path + linux: /Volumes/some/path + win: C:/some/path +``` + +You can also use platform keys when prepending values to a variable. +``` +PATH: + - mac: $MODULE/macattack + linux: $MODULE/penguin + win: $MODULE/squares +``` + +Reuse environment variables to simplify things. +``` +BASE: $MODULE/$PLATFORM/base +PATH: + - $BASE/bin +PYTHONPATH: + - $BASE/python +``` + +#### Advanced +The implicit set and prepend operations above cover the most common use cases when modifying environment variables. For more advanced use cases you can use the following explicit operation keys. +``` +SVAR: + set: + - Value0 + - Value1 +PVAR: + prepend: + - X +RVAR: + unset: 1 +PATH: + remove: + - C:/Python27 + - C:/Python27/Scripts +PYTHONPATH: + append: + - $MODULE/python + - $MODULE/lib +``` + +You can also uses lists of opreations to perform complex modifications. +``` +PATH: + - remove: /some/file/path + - append: /some/other/path + - prepend: /one/more/path +``` + +One workflow that this enables is the use of modules solely for the purpose of overriding environment variables. Imagine you have a module `my_tool` and it uses a variable `MY_TOOL_PLUGINS` to lookup plugins. +``` +name: my_tool +... +environment: + MY_TOOL_PLUGINS: + - //studio/dev/my_tool/plugins + - //studio/projects/test_project/plugins +``` + +Now imagine you have a new project and you want `my_tool` to look at a different location for plugins just for that project. Rather than create a new version of the `my_tool` module, create a override module. We might name this module after our project, `project_b`. +``` +name: project_b +... +environment: + MY_TOOL_PLUGINS: + set: + - //studio/prod/my_tool/plugins + - //studio/projects/project_b/plugins +``` + +All we have to do is activate `my_tool` and `project_b` in that order to make sure our overrides are used. +``` +> cpenv activate my_tool project_b +``` + +#### Requires key +The requires key is a list of dependencies that a module needs to function. Currently this is only used for reference, these modules will not be activated automatically. + +## Test a Module +When you're working on a module navigate into it's root directory. Then you can activate it using `cpenv activate .`. This is +the best way to validate your module prior to publishing. + +## Publish a Module +Once you're Module is ready for production, use `cpenv publish .` to publish it. Publishing a Module uploads it to a Repo of your choosing. + +# Repos +Repos are storage locations for Modules that support finding, listing, uploading, and downloading Modules via *requirements* like +`my_module-0.1.0`. Cpenv is configured with the following LocalRepos by default: + +- **cwd** - Your current working directory +- **user** - A user specific repo +- **home** - A machine wide repo + +Use `cpenv repo list` to display your configured Repos. LocalRepos point directly to folders on your local file system. +Customize the home Repo by setting the `CPENV_HOME` environment variable. + +When you activate a module using a requirement, all configured Repos are searched and the best match is used. If the resolved +module is not in a LocalRepo it will be downloaded to your home Repo then activated. This is one of the key features of cpenv +and allows for strong distributed workflows. For example, you can configure a remote repo like the ShotgunRepo and store your modules directly in a +[Shotgun studio](https://www.shotgunsoftware.com/) database. [Visit the tk-cpenv repository for more info on using cpenv with Shotgun](https://github.com/cpenv/tk-cpenv) + +# Requirements +Requirements are strings used to resolve and activate modules in Repos. They can be versionless like `my_module` or require a +version like `my_module-0.1.0`. Cpenv supports semver/calver, simple versions (v1), and what I like to call *weird* versions +like 12.0v2 (The Foundry products). In the future cpenv may support more complex requirements by utilizing +[resolvelib](https://github.com/sarugaku/resolvelib). + + +%package -n python3-cpenv +Summary: Cross-platform module and environment management. +Provides: python-cpenv +BuildRequires: python3-devel +BuildRequires: python3-setuptools +BuildRequires: python3-pip +%description -n python3-cpenv +<p align="center"> + <img src="https://raw.github.com/cpenv/cpenv/master/res/icon_dark.png"/> +</p> + +# cpenv +Manage software plugins, project dependencies and environment +variables using Modules. + +<p align="center"> + <img src="https://raw.github.com/cpenv/cpenv/master/res/demo.gif"/> +</p> + +# Installation +The recommended method of installing cpenv is via [pipx](https://pipxproject.github.io/pipx). +Pipx is used to install python cli applications in isolation. + +``` +pipx install cpenv +``` +``` +pipx upgrade cpenv +``` +``` +pipx uninstall cpenv +``` + +# Overview +Cpenv is a cli tool and python library used to create, edit, publish, and activate Modules. A Module is a folder containing a dependency, like Arnold for Maya, and a module file that configures it. + +## Environment Variables +| Variable | Description | Default | +| ------------------------ | -------------------------------------- | ------- | +| CPENV_HOME | Customize path to cpenv home | | +| CPENV_DISABLE_PROMPT | Disable prompt when modules activated | 0 | +| CPENV_ACTIVE_MODULES | List of activated modules | | +| CPENV_SHELL | Preferred subshell like "powershell" | | + +## Example Modules +- [snack](https://github.com/cpenv/snack) + +## Create a Module +Use `cpenv create <module>` to use a guide to create a new Module. +This will create a new folder in your current working directory with a module file in it. + +## Edit a Module +Each Module contains a module.yml file, referred to as a module file. A module file contains metadata like the name and version of a module, as well as configuration, like environment variables. +``` +# Variables +# $MODULE - path to this module +# $PLATFORM - platform name (win, mac, linux) +# $PYVER - python version (2.7, 3.6...) + +# Wrap variables in brackets when they are nested within a string. +# DO 'this${variable}isnested/' NOT 'this$variableisnested' + +name: 'my_module' +version: '0.1.0' +description: 'My first module.' +author: 'Me' +email: 'me@email.com' +requires: [] +environment: + MY_MODULE_VAR: 'Test' +``` + +### Environment key +Setting a value will insert a key or overwrite it's existing value. +``` +SOME_VAR: 'SOME_VALUE' +``` + +Use the $MODULE variable for module relative paths. +``` +RELATIVE_VAR: $MODULE/bin +``` + +Use lists to prepend values to a key. +``` +PATH: + - $MODULE/bin +``` + +Use `win`, `linux` and `mac or osx` keys to declare platform specific values. If you leave out a platform, the variable will not be included on that platform. +``` +PLATFORM_VAR: + mac: /mnt/some/path + linux: /Volumes/some/path + win: C:/some/path +``` + +You can also use platform keys when prepending values to a variable. +``` +PATH: + - mac: $MODULE/macattack + linux: $MODULE/penguin + win: $MODULE/squares +``` + +Reuse environment variables to simplify things. +``` +BASE: $MODULE/$PLATFORM/base +PATH: + - $BASE/bin +PYTHONPATH: + - $BASE/python +``` + +#### Advanced +The implicit set and prepend operations above cover the most common use cases when modifying environment variables. For more advanced use cases you can use the following explicit operation keys. +``` +SVAR: + set: + - Value0 + - Value1 +PVAR: + prepend: + - X +RVAR: + unset: 1 +PATH: + remove: + - C:/Python27 + - C:/Python27/Scripts +PYTHONPATH: + append: + - $MODULE/python + - $MODULE/lib +``` + +You can also uses lists of opreations to perform complex modifications. +``` +PATH: + - remove: /some/file/path + - append: /some/other/path + - prepend: /one/more/path +``` + +One workflow that this enables is the use of modules solely for the purpose of overriding environment variables. Imagine you have a module `my_tool` and it uses a variable `MY_TOOL_PLUGINS` to lookup plugins. +``` +name: my_tool +... +environment: + MY_TOOL_PLUGINS: + - //studio/dev/my_tool/plugins + - //studio/projects/test_project/plugins +``` + +Now imagine you have a new project and you want `my_tool` to look at a different location for plugins just for that project. Rather than create a new version of the `my_tool` module, create a override module. We might name this module after our project, `project_b`. +``` +name: project_b +... +environment: + MY_TOOL_PLUGINS: + set: + - //studio/prod/my_tool/plugins + - //studio/projects/project_b/plugins +``` + +All we have to do is activate `my_tool` and `project_b` in that order to make sure our overrides are used. +``` +> cpenv activate my_tool project_b +``` + +#### Requires key +The requires key is a list of dependencies that a module needs to function. Currently this is only used for reference, these modules will not be activated automatically. + +## Test a Module +When you're working on a module navigate into it's root directory. Then you can activate it using `cpenv activate .`. This is +the best way to validate your module prior to publishing. + +## Publish a Module +Once you're Module is ready for production, use `cpenv publish .` to publish it. Publishing a Module uploads it to a Repo of your choosing. + +# Repos +Repos are storage locations for Modules that support finding, listing, uploading, and downloading Modules via *requirements* like +`my_module-0.1.0`. Cpenv is configured with the following LocalRepos by default: + +- **cwd** - Your current working directory +- **user** - A user specific repo +- **home** - A machine wide repo + +Use `cpenv repo list` to display your configured Repos. LocalRepos point directly to folders on your local file system. +Customize the home Repo by setting the `CPENV_HOME` environment variable. + +When you activate a module using a requirement, all configured Repos are searched and the best match is used. If the resolved +module is not in a LocalRepo it will be downloaded to your home Repo then activated. This is one of the key features of cpenv +and allows for strong distributed workflows. For example, you can configure a remote repo like the ShotgunRepo and store your modules directly in a +[Shotgun studio](https://www.shotgunsoftware.com/) database. [Visit the tk-cpenv repository for more info on using cpenv with Shotgun](https://github.com/cpenv/tk-cpenv) + +# Requirements +Requirements are strings used to resolve and activate modules in Repos. They can be versionless like `my_module` or require a +version like `my_module-0.1.0`. Cpenv supports semver/calver, simple versions (v1), and what I like to call *weird* versions +like 12.0v2 (The Foundry products). In the future cpenv may support more complex requirements by utilizing +[resolvelib](https://github.com/sarugaku/resolvelib). + + +%package help +Summary: Development documents and examples for cpenv +Provides: python3-cpenv-doc +%description help +<p align="center"> + <img src="https://raw.github.com/cpenv/cpenv/master/res/icon_dark.png"/> +</p> + +# cpenv +Manage software plugins, project dependencies and environment +variables using Modules. + +<p align="center"> + <img src="https://raw.github.com/cpenv/cpenv/master/res/demo.gif"/> +</p> + +# Installation +The recommended method of installing cpenv is via [pipx](https://pipxproject.github.io/pipx). +Pipx is used to install python cli applications in isolation. + +``` +pipx install cpenv +``` +``` +pipx upgrade cpenv +``` +``` +pipx uninstall cpenv +``` + +# Overview +Cpenv is a cli tool and python library used to create, edit, publish, and activate Modules. A Module is a folder containing a dependency, like Arnold for Maya, and a module file that configures it. + +## Environment Variables +| Variable | Description | Default | +| ------------------------ | -------------------------------------- | ------- | +| CPENV_HOME | Customize path to cpenv home | | +| CPENV_DISABLE_PROMPT | Disable prompt when modules activated | 0 | +| CPENV_ACTIVE_MODULES | List of activated modules | | +| CPENV_SHELL | Preferred subshell like "powershell" | | + +## Example Modules +- [snack](https://github.com/cpenv/snack) + +## Create a Module +Use `cpenv create <module>` to use a guide to create a new Module. +This will create a new folder in your current working directory with a module file in it. + +## Edit a Module +Each Module contains a module.yml file, referred to as a module file. A module file contains metadata like the name and version of a module, as well as configuration, like environment variables. +``` +# Variables +# $MODULE - path to this module +# $PLATFORM - platform name (win, mac, linux) +# $PYVER - python version (2.7, 3.6...) + +# Wrap variables in brackets when they are nested within a string. +# DO 'this${variable}isnested/' NOT 'this$variableisnested' + +name: 'my_module' +version: '0.1.0' +description: 'My first module.' +author: 'Me' +email: 'me@email.com' +requires: [] +environment: + MY_MODULE_VAR: 'Test' +``` + +### Environment key +Setting a value will insert a key or overwrite it's existing value. +``` +SOME_VAR: 'SOME_VALUE' +``` + +Use the $MODULE variable for module relative paths. +``` +RELATIVE_VAR: $MODULE/bin +``` + +Use lists to prepend values to a key. +``` +PATH: + - $MODULE/bin +``` + +Use `win`, `linux` and `mac or osx` keys to declare platform specific values. If you leave out a platform, the variable will not be included on that platform. +``` +PLATFORM_VAR: + mac: /mnt/some/path + linux: /Volumes/some/path + win: C:/some/path +``` + +You can also use platform keys when prepending values to a variable. +``` +PATH: + - mac: $MODULE/macattack + linux: $MODULE/penguin + win: $MODULE/squares +``` + +Reuse environment variables to simplify things. +``` +BASE: $MODULE/$PLATFORM/base +PATH: + - $BASE/bin +PYTHONPATH: + - $BASE/python +``` + +#### Advanced +The implicit set and prepend operations above cover the most common use cases when modifying environment variables. For more advanced use cases you can use the following explicit operation keys. +``` +SVAR: + set: + - Value0 + - Value1 +PVAR: + prepend: + - X +RVAR: + unset: 1 +PATH: + remove: + - C:/Python27 + - C:/Python27/Scripts +PYTHONPATH: + append: + - $MODULE/python + - $MODULE/lib +``` + +You can also uses lists of opreations to perform complex modifications. +``` +PATH: + - remove: /some/file/path + - append: /some/other/path + - prepend: /one/more/path +``` + +One workflow that this enables is the use of modules solely for the purpose of overriding environment variables. Imagine you have a module `my_tool` and it uses a variable `MY_TOOL_PLUGINS` to lookup plugins. +``` +name: my_tool +... +environment: + MY_TOOL_PLUGINS: + - //studio/dev/my_tool/plugins + - //studio/projects/test_project/plugins +``` + +Now imagine you have a new project and you want `my_tool` to look at a different location for plugins just for that project. Rather than create a new version of the `my_tool` module, create a override module. We might name this module after our project, `project_b`. +``` +name: project_b +... +environment: + MY_TOOL_PLUGINS: + set: + - //studio/prod/my_tool/plugins + - //studio/projects/project_b/plugins +``` + +All we have to do is activate `my_tool` and `project_b` in that order to make sure our overrides are used. +``` +> cpenv activate my_tool project_b +``` + +#### Requires key +The requires key is a list of dependencies that a module needs to function. Currently this is only used for reference, these modules will not be activated automatically. + +## Test a Module +When you're working on a module navigate into it's root directory. Then you can activate it using `cpenv activate .`. This is +the best way to validate your module prior to publishing. + +## Publish a Module +Once you're Module is ready for production, use `cpenv publish .` to publish it. Publishing a Module uploads it to a Repo of your choosing. + +# Repos +Repos are storage locations for Modules that support finding, listing, uploading, and downloading Modules via *requirements* like +`my_module-0.1.0`. Cpenv is configured with the following LocalRepos by default: + +- **cwd** - Your current working directory +- **user** - A user specific repo +- **home** - A machine wide repo + +Use `cpenv repo list` to display your configured Repos. LocalRepos point directly to folders on your local file system. +Customize the home Repo by setting the `CPENV_HOME` environment variable. + +When you activate a module using a requirement, all configured Repos are searched and the best match is used. If the resolved +module is not in a LocalRepo it will be downloaded to your home Repo then activated. This is one of the key features of cpenv +and allows for strong distributed workflows. For example, you can configure a remote repo like the ShotgunRepo and store your modules directly in a +[Shotgun studio](https://www.shotgunsoftware.com/) database. [Visit the tk-cpenv repository for more info on using cpenv with Shotgun](https://github.com/cpenv/tk-cpenv) + +# Requirements +Requirements are strings used to resolve and activate modules in Repos. They can be versionless like `my_module` or require a +version like `my_module-0.1.0`. Cpenv supports semver/calver, simple versions (v1), and what I like to call *weird* versions +like 12.0v2 (The Foundry products). In the future cpenv may support more complex requirements by utilizing +[resolvelib](https://github.com/sarugaku/resolvelib). + + +%prep +%autosetup -n cpenv-0.5.34 + +%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-cpenv -f filelist.lst +%dir %{python3_sitelib}/* + +%files help -f doclist.lst +%{_docdir}/* + +%changelog +* Mon May 15 2023 Python_Bot <Python_Bot@openeuler.org> - 0.5.34-1 +- Package Spec generated @@ -0,0 +1 @@ +92fe99e7784202c0fa911ff656571190 cpenv-0.5.34.tar.gz |