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
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
|
%global _empty_manifest_terminate_build 0
Name: python-pessimist
Version: 0.9.3
Release: 1
Summary: Ensures your dependencies work with minimum version
License: MIT
URL: https://github.com/python-packaging/pessimist/
Source0: https://mirrors.aliyun.com/pypi/web/packages/36/9e/50a29c11bcb571c12497a929bf599a5cc264440b584052517652b8beace4/pessimist-0.9.3.tar.gz
BuildArch: noarch
Requires: python3-volatile
Requires: python3-toml
Requires: python3-pep517
Requires: python3-honesty
Requires: python3-highlighter
Requires: python3-setuptools
Requires: python3-click
%description
# pessimist
The name "optimist" was already taken?
Given your listed requirements, and how to run your tests, tries various
versions to ensure the minimums are accurate.
## Usage
```
python -m pessimist [-c 'make test'] [--fast] [--extend=name[,name...]] [--requirements=requirements*.txt] /path/to/repo
```
* `-c` -- command to run. If you're using a src/ layout you can use `cd src;
python -m unittest` or so.
* `--fast` -- only verify min and max versions
* `--extend` -- ignore specifiers entirely for the listed canonical names;
intended to let you go back past `==` and may be improved to do something more
like that in the future. Also allows `*` as a name to mean all names that are
"variable"
* `--requirements` -- comma-separated globs which represented "fixed"
requirements.
* `--verbose` -- show logs as it's working
## Fixed and variable
* Fixed requirements are from `requirements*.txt`. If these match more than one
version, only the newest is kept.
* Variable requirements are from your setup.py/setup.cfg/etc that make it into
the metadata. These are the ones we're interested in trying.
* If a name is in both sets, the variable logic is followed.
## Strategy
1. Try newest versions of everything. Bail if this fails to pass.
2. For each dep independently, try progressively older versions.
3. Try oldest versions of all. Bail if this fails to pass.
I subscribe to the "requirements.txt should be concrete versions you want to
use in CI" school of thought; the constraints in setup.py/setup.cfg/pyproject.toml
should be `>=` the minimum version that works, and `<` the next major version
("compatible", in poetry terms).
My goal in creating this is to have an automated check that we haven't broken
compatibility with an older version unintentionally. You could have a simpler
version of this that does `sed -e 's/>=/==/` on your requirements files, but if
that fails, finding the new minimum is still a research projct that's automated
by this one.
# License
pessimist is copyright [Tim Hatch](https://timhatch.com/), and licensed under
the MIT license. I am providing code in this repository to you under an open
source license. This is my personal repository; the license you receive to
my code is from me and not from my employer. See the `LICENSE` file for details.
%package -n python3-pessimist
Summary: Ensures your dependencies work with minimum version
Provides: python-pessimist
BuildRequires: python3-devel
BuildRequires: python3-setuptools
BuildRequires: python3-pip
%description -n python3-pessimist
# pessimist
The name "optimist" was already taken?
Given your listed requirements, and how to run your tests, tries various
versions to ensure the minimums are accurate.
## Usage
```
python -m pessimist [-c 'make test'] [--fast] [--extend=name[,name...]] [--requirements=requirements*.txt] /path/to/repo
```
* `-c` -- command to run. If you're using a src/ layout you can use `cd src;
python -m unittest` or so.
* `--fast` -- only verify min and max versions
* `--extend` -- ignore specifiers entirely for the listed canonical names;
intended to let you go back past `==` and may be improved to do something more
like that in the future. Also allows `*` as a name to mean all names that are
"variable"
* `--requirements` -- comma-separated globs which represented "fixed"
requirements.
* `--verbose` -- show logs as it's working
## Fixed and variable
* Fixed requirements are from `requirements*.txt`. If these match more than one
version, only the newest is kept.
* Variable requirements are from your setup.py/setup.cfg/etc that make it into
the metadata. These are the ones we're interested in trying.
* If a name is in both sets, the variable logic is followed.
## Strategy
1. Try newest versions of everything. Bail if this fails to pass.
2. For each dep independently, try progressively older versions.
3. Try oldest versions of all. Bail if this fails to pass.
I subscribe to the "requirements.txt should be concrete versions you want to
use in CI" school of thought; the constraints in setup.py/setup.cfg/pyproject.toml
should be `>=` the minimum version that works, and `<` the next major version
("compatible", in poetry terms).
My goal in creating this is to have an automated check that we haven't broken
compatibility with an older version unintentionally. You could have a simpler
version of this that does `sed -e 's/>=/==/` on your requirements files, but if
that fails, finding the new minimum is still a research projct that's automated
by this one.
# License
pessimist is copyright [Tim Hatch](https://timhatch.com/), and licensed under
the MIT license. I am providing code in this repository to you under an open
source license. This is my personal repository; the license you receive to
my code is from me and not from my employer. See the `LICENSE` file for details.
%package help
Summary: Development documents and examples for pessimist
Provides: python3-pessimist-doc
%description help
# pessimist
The name "optimist" was already taken?
Given your listed requirements, and how to run your tests, tries various
versions to ensure the minimums are accurate.
## Usage
```
python -m pessimist [-c 'make test'] [--fast] [--extend=name[,name...]] [--requirements=requirements*.txt] /path/to/repo
```
* `-c` -- command to run. If you're using a src/ layout you can use `cd src;
python -m unittest` or so.
* `--fast` -- only verify min and max versions
* `--extend` -- ignore specifiers entirely for the listed canonical names;
intended to let you go back past `==` and may be improved to do something more
like that in the future. Also allows `*` as a name to mean all names that are
"variable"
* `--requirements` -- comma-separated globs which represented "fixed"
requirements.
* `--verbose` -- show logs as it's working
## Fixed and variable
* Fixed requirements are from `requirements*.txt`. If these match more than one
version, only the newest is kept.
* Variable requirements are from your setup.py/setup.cfg/etc that make it into
the metadata. These are the ones we're interested in trying.
* If a name is in both sets, the variable logic is followed.
## Strategy
1. Try newest versions of everything. Bail if this fails to pass.
2. For each dep independently, try progressively older versions.
3. Try oldest versions of all. Bail if this fails to pass.
I subscribe to the "requirements.txt should be concrete versions you want to
use in CI" school of thought; the constraints in setup.py/setup.cfg/pyproject.toml
should be `>=` the minimum version that works, and `<` the next major version
("compatible", in poetry terms).
My goal in creating this is to have an automated check that we haven't broken
compatibility with an older version unintentionally. You could have a simpler
version of this that does `sed -e 's/>=/==/` on your requirements files, but if
that fails, finding the new minimum is still a research projct that's automated
by this one.
# License
pessimist is copyright [Tim Hatch](https://timhatch.com/), and licensed under
the MIT license. I am providing code in this repository to you under an open
source license. This is my personal repository; the license you receive to
my code is from me and not from my employer. See the `LICENSE` file for details.
%prep
%autosetup -n pessimist-0.9.3
%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-pessimist -f filelist.lst
%dir %{python3_sitelib}/*
%files help -f doclist.lst
%{_docdir}/*
%changelog
* Tue Jun 20 2023 Python_Bot <Python_Bot@openeuler.org> - 0.9.3-1
- Package Spec generated
|
