Spec URL: http://dl.jujens.eu/SPECS/python-pytoml.spec SRPM URL: http://dl.jujens.eu/SRPMS/python-pytoml-0.1.10-1.gitd883c7c.fc24.src.rpm Description: A parser for TOML-0.4.0 Fedora Account System Username: jujens
Hi! Why is this desirable when there is python-toml package in Fedora currently? (I'm looking to do a review swap for https://bugzilla.redhat.com/show_bug.cgi?id=1343608, but I want to make sure that this isn't just an oversight.) Thanks, - mulhern
> I want to make sure that this isn't just an oversight. It's not an oversight. I am the maintainer of python-toml. > Why is this desirable when there is python-toml package in Fedora currently? I initially used python-toml in my applications. But the support for TOML 4 is not complete. I tried to improve it (I contributed for inline object support) but the maintainer is slow to respond and still hasn't published a new version with this support. Furthermore, I find the code hard to read and modify. From what I looked at pytoml, it is better written, has a better support of toml including edge cases. I'd recommend python-pytoml but for some usage, python-toml will do the trick just fine (I find it a little easier to use). That's why I'll keep maintaining it for the foreseeable future.
Forgot to mention, I am OK for the review swap.
(In reply to Julien Enselme from comment #2) > > I want to make sure that this isn't just an oversight. > > It's not an oversight. I am the maintainer of python-toml. > > > Why is this desirable when there is python-toml package in Fedora currently? > > I initially used python-toml in my applications. But the support for TOML 4 > is not complete. I tried to improve it (I contributed for inline object > support) but the maintainer is slow to respond and still hasn't published a > new version with this support. Furthermore, I find the code hard to read and > modify. From what I looked at pytoml, it is better written, has a better > support of toml including edge cases. > > I'd recommend python-pytoml but for some usage, python-toml will do the > trick just fine (I find it a little easier to use). That's why I'll keep > maintaining it for the foreseeable future. Great, that makes sense. And thanks for agreeing to the swap!
I think it would be helpful to put what you told me in Comment #2 in the spec file as a comment, to make it as clear as possible why there are two packages that seem to provide the same functionality in Fedora.
Typo: ^unversinned^unversioned
Would be good to justify git release, as opposed to taking a published release from pypi: https://pypi.python.org/pypi/pytoml. I can't see any reason, actually.
Created attachment 1178487 [details] review file Completed review template.
Other than Comment #5, Comment #6, Comment #7 it looks good.
(In reply to mulhern from comment #7) > Would be good to justify git release, as opposed to taking a published > release from pypi: https://pypi.python.org/pypi/pytoml. I can't see any > reason, actually. always better to take "real source" from github, not "precompiled source" from PyPI.
(In reply to Igor Gnatenko from comment #10) > (In reply to mulhern from comment #7) > > Would be good to justify git release, as opposed to taking a published > > release from pypi: https://pypi.python.org/pypi/pytoml. I can't see any > > reason, actually. > always better to take "real source" from github, not "precompiled source" > from PyPI. I have been taught other way. Could you point me at docs/explanation?
Actually, if doing the install from github, it should be easy to run the tests as a %check using the instructions in the upstream README.
> I think it would be helpful to put what you told me in Comment #2 in the spec file as a comment, to make it as clear as possible why there are two packages that seem to provide the same functionality in Fedora. Done. > Typo: ^unversinned^unversioned In fact, this comment is useless here. I did a copy/paste from another SPEC in which it was. I'll correct the type there. Comment removed. > Would be good to justify git release, as opposed to taking a published release from pypi: https://pypi.python.org/pypi/pytoml. I tend to prefer pypi (no need to bother about commits) and remove pre built egg-info. However, here the license file was missing in the zip file from pypi. So I chose github. I just added a comment for that. > Actually, if doing the install from github, it should be easy to run the tests as a %check using the instructions in the upstream README. Sadly no. We can't just use git submodules because it requires network access and pull code that is not from the package. The good way to do this would be to package the go program that include the tests file. I did that for python-toml that rely on golang-github-BurntSushi-toml-test. The problem is pytoml cannot pass this suite since it is outdated. The maintainer of pytoml uses his own fork of golang-github-BurntSushi-toml-test which has no release. So until improvement on that side, I think it's better not to run check within %check and trust the upstream maintainer not to release broken stuff. Adding a comment about that in the SPEC for future information. SPEC: http://dl.jujens.eu/SPECS/python-pytoml.spec SRPM: http://dl.jujens.eu/SRPMS/python-pytoml-0.1.10-2.gitd883c7c.fc24.src.rpm
(In reply to mulhern from comment #11) > (In reply to Igor Gnatenko from comment #10) > > (In reply to mulhern from comment #7) > > > Would be good to justify git release, as opposed to taking a published > > > release from pypi: https://pypi.python.org/pypi/pytoml. I can't see any > > > reason, actually. > > always better to take "real source" from github, not "precompiled source" > > from PyPI. > > I have been taught other way. Could you point me at docs/explanation? let me show example: we have some module which uses Cython which means real source is *.pyx and *.pxi, but usually maintainer of module uploads archive just with already cythonized version (auto-generated *.c files) which can contain bugs due to broken cython on developer machine. sometimes they ship *.pyx files as well, but often I have to manually remove *.c files to really use my Cython.
All set. Thanks for the swap!
Thanks!
Package request has been approved: https://admin.fedoraproject.org/pkgdb/package/rpms/python-pytoml
python-pytoml-0.1.10-2.gitd883c7c.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-21c1d3a893
python-pytoml-0.1.10-2.gitd883c7c.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-001c6c5a66
python-pytoml-0.1.10-2.gitd883c7c.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-001c6c5a66
python-pytoml-0.1.10-2.gitd883c7c.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-21c1d3a893
python-pytoml-0.1.10-2.gitd883c7c.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
python-pytoml-0.1.10-2.gitd883c7c.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.