4:32 a.m.
Hello Pythonistas.
I find myself cop-pasting this boring snippet each time I create a Python
package (using the old macros or the new):
%package -n python3-foo
Summary: %{summary}
%description -n python3-foo %_description
And using one of those in %files:
%files -n python3-foo
%files -n python3-foo -f %{pyproject_files}
I wonder whether it makes sense to macronize this.
For example:
Name: python-foo
...
%global _description %{expand:
This is the description for both SRPM and the python3-foo package.}
%description %_description
%py3_package %_description
...
%py3_files
...
Or maybe even (if possible):
Name: python-foo
...
%py3_package_with_description
This is the description for both SRPM and the python3-foo package.
...
%py3_files
...
Both macros would figure the package name by replacing the python- prefix from
%{name} with python3-.
Pros: No more copy-paste-edit \o/
Cons: The more is hidden from the reader behind automagic macros, the less
obvious is the spec file to somebody who tries to read or modify it :(
What is your opinion?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
2:22 p.m.
Hi Miro,
in general I think explicit is better than implicit
(and since I am Dutch, this seems obvious to me).
But regarding your question, I think a better argument for creating a
macro is to prevent mistakes from packagers. I think that is more
relevant than avoiding a few lines of code in a spec file.
For myself, I am happy as long as I can find or print the definition of
a macro easily. For some this is easy enough, i.e.:
rpm --eval '%py3_install'
\
CFLAGS="${CFLAGS:-${RPM_OPT_FLAGS}}"
LDFLAGS="${LDFLAGS:-${RPM_LD_FLAGS}}"\
/usr/bin/python3 setup.py install -O1 --skip-build --root
$HOME/rpmbuild/BUILDROOT/%{NAME}-%{VERSION}-%{RELEASE}.x86_64
rm -rfv
$HOME/rpmbuild/BUILDROOT/%{NAME}-%{VERSION}-%{RELEASE}.x86_64/usr/bin/__pycache__
and this also illustrates my earlier point, since I am sure I would
forget setting this CFLAGS and LD_FLAGS often (are they really needed
for plain python packages?).
But for other macros this just doesn't work, i.e.:
rpm --eval '%autosetup'
error: lua script failed:
attempt to index a nil value
And actually, it is also not obvious to me where this one is defined (a
grep on the files in /usr/lib/rpm/macros.d/ did not tell me anything
relevant).
Cheers,
Jos.
On 3/16/21 10:32 AM, Miro Hrončok wrote:
Hello Pythonistas.
I find myself cop-pasting this boring snippet each time I create a
Python package (using the old macros or the new):
%package -n python3-foo
Summary: %{summary}
%description -n python3-foo %_description
And using one of those in %files:
%files -n python3-foo
%files -n python3-foo -f %{pyproject_files}
I wonder whether it makes sense to macronize this.
For example:
Name: python-foo
...
%global _description %{expand:
This is the description for both SRPM and the python3-foo package.}
%description %_description
%py3_package %_description
...
%py3_files
...
Or maybe even (if possible):
Name: python-foo
...
%py3_package_with_description
This is the description for both SRPM and the python3-foo package.
...
%py3_files
...
Both macros would figure the package name by replacing the python-
prefix from %{name} with python3-.
Pros: No more copy-paste-edit \o/
Cons: The more is hidden from the reader behind automagic macros, the
less obvious is the spec file to somebody who tries to read or modify it :(
What is your opinion?
4:36 p.m.
On 16. 03. 21 20:22, Jos de Kloe wrote:
Hi Miro,
in general I think explicit is better than implicit
(and since I am Dutch, this seems obvious to me).
:D
But regarding your question, I think a better argument for creating a
macro is
to prevent mistakes from packagers. I think that is more relevant than avoiding
a few lines of code in a spec file.
The examples I've put are really not that complex as %py3_build/%py3_install, so
I don't think "error prevention" would apply for them.
For myself, I am happy as long as I can find or print the definition
of a macro
easily. For some this is easy enough, i.e.:
> rpm --eval '%py3_install'
\
CFLAGS="${CFLAGS:-${RPM_OPT_FLAGS}}"
LDFLAGS="${LDFLAGS:-${RPM_LD_FLAGS}}"\
/usr/bin/python3 setup.py install -O1 --skip-build --root
$HOME/rpmbuild/BUILDROOT/%{NAME}-%{VERSION}-%{RELEASE}.x86_64
rm -rfv
$HOME/rpmbuild/BUILDROOT/%{NAME}-%{VERSION}-%{RELEASE}.x86_64/usr/bin/__pycache__
and this also illustrates my earlier point, since I am sure I would forget
setting this CFLAGS and LD_FLAGS often (are they really needed for plain python
packages?).
No, they are not needed for noarch packages, but they are needed or extension
modules and since we don't want a different set of macros for noarch/arch, we
set it everywhere.
But for other macros this just doesn't work, i.e.:
> rpm --eval '%autosetup'
error: lua script failed: attempt to index a nil value
Yes, some macros need the context defined in the spec file, this one needs a
defined source.
And actually, it is also not obvious to me where this one is defined
(a grep on
the files in /usr/lib/rpm/macros.d/ did not tell me anything relevant).
This macro is defined directly in the /usr/lib/rpm/macros file.
Cheers,
Thanks for the input Jos, I really appreciate it.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1:23 a.m.
Hi.
On 3/16/21 8:22 PM, Jos de Kloe wrote:
Hi Miro,
in general I think explicit is better than implicit
(and since I am Dutch, this seems obvious to me).
I agree with Jos here. From my
recent experience with onbording a new
packager it seems that our macros (old and new ones) are just enough
level of abstraction but the overall specfile still looks like other
specfiles and that's good. You never know when somebody needs to update
a Python specfile and if they have a different background, it's good
that they can understand at least the core structure of the specfile.
But regarding your question, I think a better argument for creating a
macro is to prevent mistakes from packagers. I think that is more
relevant than avoiding a few lines of code in a spec file.
For myself, I am happy as long as I can find or print the definition
of a macro easily. For some this is easy enough, i.e.:
> rpm --eval '%py3_install'
\
CFLAGS="${CFLAGS:-${RPM_OPT_FLAGS}}"
LDFLAGS="${LDFLAGS:-${RPM_LD_FLAGS}}"\
/usr/bin/python3 setup.py install -O1 --skip-build --root
$HOME/rpmbuild/BUILDROOT/%{NAME}-%{VERSION}-%{RELEASE}.x86_64
rm -rfv
$HOME/rpmbuild/BUILDROOT/%{NAME}-%{VERSION}-%{RELEASE}.x86_64/usr/bin/__pycache__
and this also illustrates my earlier point, since I am sure I would
forget setting this CFLAGS and LD_FLAGS often (are they really needed
for plain python packages?).
But for other macros this just doesn't work, i.e.:
> rpm --eval '%autosetup'
error: lua script failed: attempt to index a nil value
And actually, it is also not obvious to me where this one is defined
(a grep on the files in /usr/lib/rpm/macros.d/ did not tell me
anything relevant).
Cheers,
Jos.
On 3/16/21 10:32 AM, Miro Hrončok wrote:
> Hello Pythonistas.
>
>
> I find myself cop-pasting this boring snippet each time I create a
> Python package (using the old macros or the new):
>
>
> %package -n python3-foo
> Summary: %{summary}
>
> %description -n python3-foo %_description
>
> And using one of those in %files:
>
> %files -n python3-foo
> %files -n python3-foo -f %{pyproject_files}
>
> I wonder whether it makes sense to macronize this.
>
> For example:
>
> Name: python-foo
> ...
>
> %global _description %{expand:
> This is the description for both SRPM and the python3-foo package.}
>
> %description %_description
>
> %py3_package %_description
>
> ...
>
> %py3_files
> ...
>
>
> Or maybe even (if possible):
>
> Name: python-foo
> ...
>
> %py3_package_with_description
> This is the description for both SRPM and the python3-foo package.
>
> ...
>
> %py3_files
> ...
>
>
> Both macros would figure the package name by replacing the python-
> prefix from %{name} with python3-.
>
>
> Pros: No more copy-paste-edit \o/
>
> Cons: The more is hidden from the reader behind automagic macros, the
> less obvious is the spec file to somebody who tries to read or modify
> it :(
>
>
> What is your opinion?
_______________________________________________
python-devel mailing list -- python-devel(a)lists.fedoraproject.org
To unsubscribe send an email to
python-devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedorapr...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
2:29 p.m.
On Tue, Mar 16, 2021 at 5:32 AM Miro Hrončok <mhroncok(a)redhat.com> wrote:
Hello Pythonistas.
I find myself cop-pasting this boring snippet each time I create a Python
package (using the old macros or the new):
%package -n python3-foo
Summary: %{summary}
%description -n python3-foo %_description
And using one of those in %files:
%files -n python3-foo
%files -n python3-foo -f %{pyproject_files}
I wonder whether it makes sense to macronize this.
For example:
Name: python-foo
...
%global _description %{expand:
This is the description for both SRPM and the python3-foo package.}
%description %_description
%py3_package %_description
...
%py3_files
...
Or maybe even (if possible):
Name: python-foo
...
%py3_package_with_description
This is the description for both SRPM and the python3-foo package.
...
%py3_files
...
Both macros would figure the package name by replacing the python- prefix from
%{name} with python3-.
Pros: No more copy-paste-edit \o/
Cons: The more is hidden from the reader behind automagic macros, the less
obvious is the spec file to somebody who tries to read or modify it :(
What is your opinion?
I would actually like this, and make it easy for us to build for
multiple Pythons (even if we don't do it by default in Fedora). This
is how openSUSE works with their "singlespec" model[1], and I have
come to appreciate it, even though I don't like some of the details of
the openSUSE implementation (such as weird parsing and rewriting of
stanzas for dependencies instead of the use of a generator and the
usage of alternatives, as shown in this example[2]).
[1]: https://en.opensuse.org/openSUSE:Packaging_Python#What_is_single-spec.3F
[2]:
https://build.opensuse.org/package/view_file/devel:languages:python:flask...
--
真実はいつも一つ！/ Always, there's only one truth!
1129
days inactive
1130
days old
python-devel@lists.fedoraproject.org
4 comments
4 participants
participants (4)
-
Jos de Kloe -
Lumír Balhar -
Miro Hrončok -
Neal Gompa