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
|
%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
|
