diff options
Diffstat (limited to 'python-any-case.spec')
| -rw-r--r-- | python-any-case.spec | 138 |
1 files changed, 138 insertions, 0 deletions
diff --git a/python-any-case.spec b/python-any-case.spec new file mode 100644 index 0000000..75caf7c --- /dev/null +++ b/python-any-case.spec @@ -0,0 +1,138 @@ +%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 <Python_Bot@openeuler.org> - 0.1.6-1 +- Package Spec generated |