%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 - 1.2.0-1 - Package Spec generated