Bug 1130098

Summary:	Review Request: python-ejson - Extensible json serializer/deserializer library
Product:	[Fedora] Fedora	Reporter:	Pavel Alexeev <pahan>
Component:	Package Review	Assignee:	Nobody's working on this, feel free to take it <nobody>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	package-review, pahan, quantum.analyst
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-01-16 01:32:30 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	201449, 1130103

Description Pavel Alexeev 2014-08-14 10:32:23 UTC

Spec URL: https://raw.githubusercontent.com/Hubbitus/Fedora-packaging/master/SPECS/python-ejson.spec
SRPM URL: http://hubbitus.info/rpm/Fedora20/python-ejson/python-ejson-0.1.6-1.fc20.src.rpm
Description: There are countless scenarios that we need to exchange data between
different systems, implemented in different languages and technologies.
Even in the same system, when implementing data exchange between the
backend and the frontend we face the need to convert the language data
types to another format and then do the oposite when the data arrives in
the other side of the wire.

A very simple and flexible format that seems to fit most of our needs is
the JavaScript Object Notation, or simple `json`. It is very hard to
find a programming language these days that does not support it, even
the low level ones, like C, C++, etc.

Json is enough when we need to exchange data types like integers,
doubles, strings, lists and hash tables. The problem starts when we need
to exchange a complex data type. And it's the exact aim of this
document: providing an API to extend the `json` library to make it easy
to register new serializers and new deserializers.

Fedora Account System Username: Hubbitus

Comment 1 Igor Gnatenko 2016-07-18 18:29:34 UTC

unfortunately it is completely out of sync with guidelines.

* must be split to python2- and python3- subpackages
* must use %python_provide macro for them
* should use new macroses %py2_build, %py3_build, %py2_install, %py3_install
* must not use unversioned %{python_sitelib}
* should drop %{!?python_sitelib: %global python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())")} and sitearch macroses like that (it's needed only for EL5)

Comment 2 Germano Massullo (Thetra) 2016-07-18 18:30:44 UTC

Hello. Your spec file is not compliant to Fedora Python Packaging Guidelines
https://fedoraproject.org/wiki/Packaging:Python#Example_common_spec_file
for instance, there is not distinction between Python 2 and 3 packages.
You can take as example my spec file of python-netdiff
http://pkgs.fedoraproject.org/cgit/rpms/python-netdiff.git/tree/python-netdiff.spec

Comment 3 Igor Gnatenko 2016-11-14 17:11:43 UTC

ping?

Comment 4 Elliott Sales de Andrade 2019-01-16 01:32:30 UTC

I think it's time to close this.

Comment 5 Red Hat Bugzilla 2023-09-14 02:45:41 UTC

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days