%global _empty_manifest_terminate_build 0 Name: python-any-case Version: 0.1.6 Release: 1 Summary: Snake/Camel case converter with Django and Djnago REST framework integration License: MIT URL: https://github.com/asduj/any_case Source0: https://mirrors.nju.edu.cn/pypi/web/packages/3b/5b/41d060ecf49f57c4558fdd2699ff018285525d98bbed359d8d07e32995d9/any_case-0.1.6.tar.gz BuildArch: noarch %description When developing a web application, you often have to choose the case format (snake_case/camelCase) will be used for the input and the output json data. If the backend is written in Python, the easiest option is to choose snake_case. On the one hand, this is good, because we have an obvious consistency, but on the other hand, the main consumers of the API (mobile and browser) prefer to use camelCase. If we care about our consumers, we will change the case format to camelCase. And it's good if we think about it in advance, before publishing API. But if this happens in an existing application, it becomes much more difficult to do so because there are consumers using the existing API. We have two options here: - introduce a new version of the api - send data in two cases at once The second option increases the size of the data, and the first option forces us to support two versions of the API without serious need. These options complicate the support and development of API. Things get a little more complicated when we have consumers who natively use snake_case, and using camelCase for them is not an option at all. As you can see, the use of one notation does not improve, but may worsen the situation. But why do we have to choose for the customer which case format they use? Why customers do not send and not receive data in the format, which would be more convenient to them? That's what this library is for. Consumers choose in what case they expect the data. If they specified an incorrect case or made a request without specifying a case, the data will be given as is. This approach allows existing consumers to work without changes with existing API, and for those consumers who want to use a single format, allows granular rewriting of the application. %package -n python3-any-case Summary: Snake/Camel case converter with Django and Djnago REST framework integration Provides: python-any-case BuildRequires: python3-devel BuildRequires: python3-setuptools BuildRequires: python3-pip %description -n python3-any-case When developing a web application, you often have to choose the case format (snake_case/camelCase) will be used for the input and the output json data. If the backend is written in Python, the easiest option is to choose snake_case. On the one hand, this is good, because we have an obvious consistency, but on the other hand, the main consumers of the API (mobile and browser) prefer to use camelCase. If we care about our consumers, we will change the case format to camelCase. And it's good if we think about it in advance, before publishing API. But if this happens in an existing application, it becomes much more difficult to do so because there are consumers using the existing API. We have two options here: - introduce a new version of the api - send data in two cases at once The second option increases the size of the data, and the first option forces us to support two versions of the API without serious need. These options complicate the support and development of API. Things get a little more complicated when we have consumers who natively use snake_case, and using camelCase for them is not an option at all. As you can see, the use of one notation does not improve, but may worsen the situation. But why do we have to choose for the customer which case format they use? Why customers do not send and not receive data in the format, which would be more convenient to them? That's what this library is for. Consumers choose in what case they expect the data. If they specified an incorrect case or made a request without specifying a case, the data will be given as is. This approach allows existing consumers to work without changes with existing API, and for those consumers who want to use a single format, allows granular rewriting of the application. %package help Summary: Development documents and examples for any-case Provides: python3-any-case-doc %description help When developing a web application, you often have to choose the case format (snake_case/camelCase) will be used for the input and the output json data. If the backend is written in Python, the easiest option is to choose snake_case. On the one hand, this is good, because we have an obvious consistency, but on the other hand, the main consumers of the API (mobile and browser) prefer to use camelCase. If we care about our consumers, we will change the case format to camelCase. And it's good if we think about it in advance, before publishing API. But if this happens in an existing application, it becomes much more difficult to do so because there are consumers using the existing API. We have two options here: - introduce a new version of the api - send data in two cases at once The second option increases the size of the data, and the first option forces us to support two versions of the API without serious need. These options complicate the support and development of API. Things get a little more complicated when we have consumers who natively use snake_case, and using camelCase for them is not an option at all. As you can see, the use of one notation does not improve, but may worsen the situation. But why do we have to choose for the customer which case format they use? Why customers do not send and not receive data in the format, which would be more convenient to them? That's what this library is for. Consumers choose in what case they expect the data. If they specified an incorrect case or made a request without specifying a case, the data will be given as is. This approach allows existing consumers to work without changes with existing API, and for those consumers who want to use a single format, allows granular rewriting of the application. %prep %autosetup -n any-case-0.1.6 %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-any-case -f filelist.lst %dir %{python3_sitelib}/* %files help -f doclist.lst %{_docdir}/* %changelog * Fri May 05 2023 Python_Bot - 0.1.6-1 - Package Spec generated