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
|
%global _empty_manifest_terminate_build 0
Name: python-vendoring
Version: 1.2.0
Release: 1
Summary: A command line tool, to simplify vendoring pure Python dependencies.
License: MIT License
URL: https://pypi.org/project/vendoring/
Source0: https://mirrors.aliyun.com/pypi/web/packages/da/bd/b92bbd4a5e6fb52c05af4fdef86726e05c38e5a36313716cf37e38183c65/vendoring-1.2.0.tar.gz
BuildArch: noarch
Requires: python3-click
Requires: python3-rich
Requires: python3-jsonschema
Requires: python3-toml
Requires: python3-requests
Requires: python3-packaging
Requires: python3-sphinx
Requires: python3-pytest
Requires: python3-pytest-cov
Requires: python3-pytest-mock
%description
# vendoring
A command line tool, to simplify vendoring pure Python dependencies.
## Why does this exist?
pip had a "home-grown" setup for vendoring dependencies. The `invoke` task grew in complexity to over 500 lines and, at some point, became extremely difficult to improve and maintain.
This tool is based off the overgrown `invoke` task, breaking it out into a dedicated codebase with the goal of making it more maintainable and reusable. This also enabled independent evolution of this codebase and better access to infrastructure (like dedicated CI) to ensure it keeps working properly.
## Should I use it?
This tool has no stability promises -- it has only one intended user: pip. There may be unannounced changes to this codebase at any time, as long as the intended user (i.e. the pip project) is prepared for those changes.
As a general rule of thumb, if the project is going to be a PyPI package, it should not use this tool.
Many downstream redistributors have policies against this kind of bundling of dependencies, which means that they'll patch your software to debundle it. This can cause various kinds of issues, due to violations of assumptions being made about where the dependencies are available/which versions are being used. These issues result in difficult-to-debug errors, which are fairly difficult to communicate with end users.
pip is a _very_ special case with a [thorough rationale][rationale] for
vendoring/bundling dependencies with itself.
[rationale]: https://pip.pypa.io/en/latest/development/vendoring-policy/#rationale
## Contributing
Check the [Contributing](CONTRIBUTING.md) guide.
%package -n python3-vendoring
Summary: A command line tool, to simplify vendoring pure Python dependencies.
Provides: python-vendoring
BuildRequires: python3-devel
BuildRequires: python3-setuptools
BuildRequires: python3-pip
%description -n python3-vendoring
# vendoring
A command line tool, to simplify vendoring pure Python dependencies.
## Why does this exist?
pip had a "home-grown" setup for vendoring dependencies. The `invoke` task grew in complexity to over 500 lines and, at some point, became extremely difficult to improve and maintain.
This tool is based off the overgrown `invoke` task, breaking it out into a dedicated codebase with the goal of making it more maintainable and reusable. This also enabled independent evolution of this codebase and better access to infrastructure (like dedicated CI) to ensure it keeps working properly.
## Should I use it?
This tool has no stability promises -- it has only one intended user: pip. There may be unannounced changes to this codebase at any time, as long as the intended user (i.e. the pip project) is prepared for those changes.
As a general rule of thumb, if the project is going to be a PyPI package, it should not use this tool.
Many downstream redistributors have policies against this kind of bundling of dependencies, which means that they'll patch your software to debundle it. This can cause various kinds of issues, due to violations of assumptions being made about where the dependencies are available/which versions are being used. These issues result in difficult-to-debug errors, which are fairly difficult to communicate with end users.
pip is a _very_ special case with a [thorough rationale][rationale] for
vendoring/bundling dependencies with itself.
[rationale]: https://pip.pypa.io/en/latest/development/vendoring-policy/#rationale
## Contributing
Check the [Contributing](CONTRIBUTING.md) guide.
%package help
Summary: Development documents and examples for vendoring
Provides: python3-vendoring-doc
%description help
# vendoring
A command line tool, to simplify vendoring pure Python dependencies.
## Why does this exist?
pip had a "home-grown" setup for vendoring dependencies. The `invoke` task grew in complexity to over 500 lines and, at some point, became extremely difficult to improve and maintain.
This tool is based off the overgrown `invoke` task, breaking it out into a dedicated codebase with the goal of making it more maintainable and reusable. This also enabled independent evolution of this codebase and better access to infrastructure (like dedicated CI) to ensure it keeps working properly.
## Should I use it?
This tool has no stability promises -- it has only one intended user: pip. There may be unannounced changes to this codebase at any time, as long as the intended user (i.e. the pip project) is prepared for those changes.
As a general rule of thumb, if the project is going to be a PyPI package, it should not use this tool.
Many downstream redistributors have policies against this kind of bundling of dependencies, which means that they'll patch your software to debundle it. This can cause various kinds of issues, due to violations of assumptions being made about where the dependencies are available/which versions are being used. These issues result in difficult-to-debug errors, which are fairly difficult to communicate with end users.
pip is a _very_ special case with a [thorough rationale][rationale] for
vendoring/bundling dependencies with itself.
[rationale]: https://pip.pypa.io/en/latest/development/vendoring-policy/#rationale
## Contributing
Check the [Contributing](CONTRIBUTING.md) guide.
%prep
%autosetup -n vendoring-1.2.0
%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-vendoring -f filelist.lst
%dir %{python3_sitelib}/*
%files help -f doclist.lst
%{_docdir}/*
%changelog
* Thu Jun 08 2023 Python_Bot <Python_Bot@openeuler.org> - 1.2.0-1
- Package Spec generated
|
