1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
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
|
