automatic import of python-vexopeneuler20.03

3 files changed, 161 insertions, 0 deletions

diff --git a/.gitignore b/.gitignore
index e69de29..4959360 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/vex-0.0.19.tar.gz
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
diff --git a/sources b/sources
new file mode 100644
index 0000000..ebad846
--- /dev/null
+++ b/sources
@@ -0,0 +1 @@
+c8b4480295e11d433374b564b57c4ccd  vex-0.0.19.tar.gz