diff options
Diffstat (limited to 'python-vex.spec')
| -rw-r--r-- | python-vex.spec | 159 |
1 files changed, 159 insertions, 0 deletions
diff --git a/python-vex.spec b/python-vex.spec new file mode 100644 index 0000000..0150fa0 --- /dev/null +++ b/python-vex.spec @@ -0,0 +1,159 @@ +%global _empty_manifest_terminate_build 0 +Name: python-vex +Version: 0.0.19 +Release: 1 +Summary: Run commands in a virtualenv +License: MIT +URL: http://github.com/sashahart/vex +Source0: https://mirrors.aliyun.com/pypi/web/packages/f3/c3/d9663276c155e054a9548e7ab6442df66c1b1b7e01546f6404c9363ad8a5/vex-0.0.19.tar.gz +BuildArch: noarch + + +%description +``vex`` just runs any command in a virtualenv, without modifying the current +shell environment. +To know why this is different, you have to understand a little about how +virtualenv normally works. +The normal way people use a virtualenv (other than virtualenvwrapper, +which does this for them) is to open a shell and source +a file called ``whatever/bin/activate``. +Sourcing this shell script modifies the environment in the current shell. +It saves the old values and sets up a shell function named ``deactivate`` +which restores those old values. When you run ``deactivate`` it restores +its saved values. +This is also the way virtualenvwrapper's ``workon`` functions - after all, it +is a wrapper for virtualenv. +If you want to use a virtualenv inside a script you probably don't use +activate, though, you just run the python that is inside the virtualenv's +bin/ directory. +The way virtualenv's activate works isn't elegant, but it usually works fine. +It's just specific to the shell, and sometimes gets a little fiddly, because of +that decision to modify the current shell environment. +The principle of ``vex`` is much simpler, and it doesn't care what shell you +use, because it does not modify the current environment. It only sets up the +environment of the new process, and those environment settings just go away +when the process does. So no ``deactivate`` or restoration of environment is +necessary. +For example, if you run ``vex foo bash`` then that bash shell has the right +environment setup, but specifically "deactivating the virtualenv" is +unnecessary; the virtualenv "deactivates" when the process ends, +e.g. if you use ``exit`` or Ctrl-D as normal to leave bash. That's just +an example with bash, it works the same with anything. +(More examples in the Examples section.) + +%package -n python3-vex +Summary: Run commands in a virtualenv +Provides: python-vex +BuildRequires: python3-devel +BuildRequires: python3-setuptools +BuildRequires: python3-pip +%description -n python3-vex +``vex`` just runs any command in a virtualenv, without modifying the current +shell environment. +To know why this is different, you have to understand a little about how +virtualenv normally works. +The normal way people use a virtualenv (other than virtualenvwrapper, +which does this for them) is to open a shell and source +a file called ``whatever/bin/activate``. +Sourcing this shell script modifies the environment in the current shell. +It saves the old values and sets up a shell function named ``deactivate`` +which restores those old values. When you run ``deactivate`` it restores +its saved values. +This is also the way virtualenvwrapper's ``workon`` functions - after all, it +is a wrapper for virtualenv. +If you want to use a virtualenv inside a script you probably don't use +activate, though, you just run the python that is inside the virtualenv's +bin/ directory. +The way virtualenv's activate works isn't elegant, but it usually works fine. +It's just specific to the shell, and sometimes gets a little fiddly, because of +that decision to modify the current shell environment. +The principle of ``vex`` is much simpler, and it doesn't care what shell you +use, because it does not modify the current environment. It only sets up the +environment of the new process, and those environment settings just go away +when the process does. So no ``deactivate`` or restoration of environment is +necessary. +For example, if you run ``vex foo bash`` then that bash shell has the right +environment setup, but specifically "deactivating the virtualenv" is +unnecessary; the virtualenv "deactivates" when the process ends, +e.g. if you use ``exit`` or Ctrl-D as normal to leave bash. That's just +an example with bash, it works the same with anything. +(More examples in the Examples section.) + +%package help +Summary: Development documents and examples for vex +Provides: python3-vex-doc +%description help +``vex`` just runs any command in a virtualenv, without modifying the current +shell environment. +To know why this is different, you have to understand a little about how +virtualenv normally works. +The normal way people use a virtualenv (other than virtualenvwrapper, +which does this for them) is to open a shell and source +a file called ``whatever/bin/activate``. +Sourcing this shell script modifies the environment in the current shell. +It saves the old values and sets up a shell function named ``deactivate`` +which restores those old values. When you run ``deactivate`` it restores +its saved values. +This is also the way virtualenvwrapper's ``workon`` functions - after all, it +is a wrapper for virtualenv. +If you want to use a virtualenv inside a script you probably don't use +activate, though, you just run the python that is inside the virtualenv's +bin/ directory. +The way virtualenv's activate works isn't elegant, but it usually works fine. +It's just specific to the shell, and sometimes gets a little fiddly, because of +that decision to modify the current shell environment. +The principle of ``vex`` is much simpler, and it doesn't care what shell you +use, because it does not modify the current environment. It only sets up the +environment of the new process, and those environment settings just go away +when the process does. So no ``deactivate`` or restoration of environment is +necessary. +For example, if you run ``vex foo bash`` then that bash shell has the right +environment setup, but specifically "deactivating the virtualenv" is +unnecessary; the virtualenv "deactivates" when the process ends, +e.g. if you use ``exit`` or Ctrl-D as normal to leave bash. That's just +an example with bash, it works the same with anything. +(More examples in the Examples section.) + +%prep +%autosetup -n vex-0.0.19 + +%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-vex -f filelist.lst +%dir %{python3_sitelib}/* + +%files help -f doclist.lst +%{_docdir}/* + +%changelog +* Tue Jun 20 2023 Python_Bot <Python_Bot@openeuler.org> - 0.0.19-1 +- Package Spec generated |