Merged #221.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/221#event-1309319368___
Rpm-maint mailing list
Dropped the ball with this one, sorry.
Also missed the fact the shebang is not used in the actual macro invocation, so
withdrawing my grumblings.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@pmatilai @Conan-Kudo ping?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/221#issuecomment-338811478___
Rpm-maint mailing list
scop commented on this pull request.
> @@ -0,0 +1,27 @@
+#!/usr/bin/python -tt
Shouldn't really matter all that much, because the script is invoked with an
explicit "outside" interpreter without the shebang affecting anything, but
meh... dropped.
--
You are receiving this because you are
@scop pushed 1 commit.
9e192ce python-macro-helper: Drop -tt from shebang
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Conan-Kudo requested changes on this pull request.
> @@ -0,0 +1,27 @@
+#!/usr/bin/python -tt
Please don't use `-tt`, as that switch is deprecated and removed in Python 3.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Rebased. @pmatilai ping?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/221#issuecomment-325380081___
Rpm-maint mailing list
I don't see how this change would affect that use case at all. Before this
change, the macros were expanded using `%{__python}`, and they still are (the
shebang in the scriptlet is not used).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or
Sorry, was on vacation for a week (and will be again for all of July)
The patch as such looks fine to me, no problem with that.
What I'm wondering about is that this of course loses is the ability to easily
override python version both at run- and buildtime. The latter isn't that
relevant
Ping?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/221#issuecomment-310887287___
Rpm-maint mailing list
Combining done, script renamed to python-macro-helper. I think the installation
point in rpm's dir structure serves as a prefix/namespace already.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I thought I already commented on this but guess not... anyway, I thought having
separate tiny scriptlets for such closely related items seemed a bit much.
`python-rpminfo` which offers switches or commands to retrieve the parameters
seems more like it. Or maybe `rpminfo-python` to prefix by the
It'll take me about a week and a half until I'll get back to this. If anyone
wants to ahead with this in the meantime, please feel free.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
`python-rpminfo`?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/221#issuecomment-306805891___
Rpm-maint mailing list
`python_sitedirs` is otherwise fine, but it will also in its current form be
used to retrieve the python version, which seems a bit odd to me. Also, perhaps
it will be extended to generate some new other macros in the future. I'm
currently thinking along the lines of `python-macrotool` or
@scop that sounds like a good idea.
I'd suggest `python_sitedirs` as the script name.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
My archive of unpacked .spec file disputes @ignatenkobrain comment above --
backward compatibility matters
[herrold@centos-7 SPECS]$ grep "\%py" *spec | grep -v ":#" | wc
39 1461953
[herrold@centos-7 SPECS]$ grep "\%py" *spec | grep -v ":#"
BitTorrent.spec:%pyrequires_eq
I am wondering if we should remove all this python stuff from RPM because no
one should use %python_sitelib due to py2/py3 things and such.. RPM doesn't
depend on python..
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Conan-Kudo approved this pull request.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/221#pullrequestreview-39478138___
Oh well, anyway, since it was not my purpose to actually make the sys.stdout ->
print changes, they're back to sys.stdout.write in this latest revision.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Oops, the print stuff is like I said in the macros shipped by Fedora's
python-rpm-macros, not here (here they were using sys.stdout.write). But the
rest of what I said still stands.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
`.py` suffixes removed.
I don't think there's anything fragile about this particular use of `print`,
nor does it require the `print_function` import. It is also nothing new, the
previous `%python_sitelib` and `%python_sitearch` definitions used it too.
--
You are receiving this because you
It's missing the `from __future__ import print_function`.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Using print() looks fragile from a Python 2 vs Python 3 POV.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Conan-Kudo requested changes on this pull request.
I would suggest renaming the files so that they don't end in `.py`. That way,
they won't be byte compiled by either the interpreter or by rpm during the
package build process.
--
You are receiving this because you are subscribed to this
25 matches
Mail list logo
