From cf00d7a58b6ae356d347e44f3b61428b4c1b87df Mon Sep 17 00:00:00 2001 From: CoprDistGit Date: Wed, 17 May 2023 04:42:45 +0000 Subject: automatic import of python-vendoring --- python-vendoring.spec | 163 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 163 insertions(+) create mode 100644 python-vendoring.spec (limited to 'python-vendoring.spec') diff --git a/python-vendoring.spec b/python-vendoring.spec new file mode 100644 index 0000000..1046315 --- /dev/null +++ b/python-vendoring.spec @@ -0,0 +1,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.nju.edu.cn/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 +* Wed May 17 2023 Python_Bot - 1.2.0-1 +- Package Spec generated -- cgit v1.2.3