I see more and more %{?sle15_python_module_pythons} and %{sle15modernpython} in packages changes. But i can't find any documentation about it. Not in wiki and not in python-rpm-macro. So what's the deal with "%{?sle15_python_module_pythons}" ? And what's the deal with "%{sle15modernpython}" ? Regards Eric
On mar, 2023-04-25 at 08:32 +0200, Eric Schirra wrote:
I see more and more %{?sle15_python_module_pythons} and %{sle15modernpython} in packages changes.
But i can't find any documentation about it. Not in wiki and not in python-rpm-macro.
So what's the deal with "%{?sle15_python_module_pythons}" ? And what's the deal with "%{sle15modernpython}" ?
This is related to SLE, we are trying to make the changes in factory to do not have different sources for the modern python packages provided there. This macro won't do anything in Tumbleweed or other versions where it's not defined and in SLE it's just to set the "pythons" macro to a different value, so the multibuild can produce python3.11 packages there. The final macro name is the first one, "%{?sle15_python_module_pythons}", the second one is a devel name and if it's in some devel package or Factory should be renamed to the other one. Regards -- Daniel García Moreno Python Packager
Hi Daniel, On 25.04.23 at 09:20 Daniel Garcia wrote:
This macro won't do anything in Tumbleweed or other versions where it's not defined and in SLE it's just to set the "pythons" macro to a different value, so the multibuild can produce python3.11 packages there.
Is there more information on this (other than the raw macros somewhere)? What is the intention behind this (I am asking because I needed to jump through quite some hoops to build ansible for SLES15 with python3.10 from the Python3 module. If this macro makes it easier to do so I would be interested...) Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
On mié, 2023-04-26 at 13:34 +0200, Johannes Kastl wrote:
Hi Daniel,
On 25.04.23 at 09:20 Daniel Garcia wrote:
This macro won't do anything in Tumbleweed or other versions where it's not defined and in SLE it's just to set the "pythons" macro to a different value, so the multibuild can produce python3.11 packages there.
Is there more information on this (other than the raw macros somewhere)? What is the intention behind this
(I am asking because I needed to jump through quite some hoops to build ansible for SLES15 with python3.10 from the Python3 module. If this macro makes it easier to do so I would be interested...)
Possibly it will make it easier, but for python 3.11. We're building a reduced list of basic python packages, the modern version, just directly from Tumbleweed, to provide it in SLE15-SP4, so it should be available, but just in the python module. Here you can find the devel project that we're using to build the list of packages and fix issues: https://build.opensuse.org/project/show/home:dirkmueller:acdc:as_python3_mod... I've just updated the initial doc in the wiki, added by Robert, with a more detailed explanation: https://en.opensuse.org/openSUSE:Packaging_Python#Python_3_(Leap_Future) Regards -- Daniel García Moreno Python Packager
Hi Daniel, thanks for the reply. On 26.04.23 at 17:51 Daniel Garcia wrote:
On mié, 2023-04-26 at 13:34 +0200, Johannes Kastl wrote:
(I am asking because I needed to jump through quite some hoops to build ansible for SLES15 with python3.10 from the Python3 module. If this macro makes it easier to do so I would be interested...)
Possibly it will make it easier, but for python 3.11.
I'll take what is avaiable in the Python3 module. :-)
We're building a reduced list of basic python packages, the modern version, just directly from Tumbleweed, to provide it in SLE15-SP4, so it should be available, but just in the python module.
Here you can find the devel project that we're using to build the list of packages and fix issues: https://build.opensuse.org/project/show/home:dirkmueller:acdc:as_python3_mod...
I've just updated the initial doc in the wiki, added by Robert, with a more detailed explanation: https://en.opensuse.org/openSUSE:Packaging_Python#Python_3_(Leap_Future)
1. Currently I set those lines in the prjconf in the SLES15+Python3 projects: ``` %define pythons python310 Macros: %pythons python310 :Macros ``` IIUC I can just remove this, once the macro was added to each package? 2. Currently I hardcode the versions for Tumbleweed and SLES15 in e.g. the ansible-core spec file: ``` %if 0%{?suse_version} < 1550 # Leap15, SLES15 %define pythons python310 %define ansible_python python310 %define ansible_python_executable python3.10 %define ansible_python_sitelib %python310_sitelib %else # Tumbleweed %define pythons python3 %define ansible_python python3 %define ansible_python_executable python3 %define ansible_python_sitelib %python3_sitelib %endif ``` I assume that this needs to be adapted to 3.11 (and possibly other versions in the future?)? Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
On mar, 2023-05-02 at 12:48 +0200, Johannes Kastl wrote:
Hi Daniel,
thanks for the reply.
On 26.04.23 at 17:51 Daniel Garcia wrote:
On mié, 2023-04-26 at 13:34 +0200, Johannes Kastl wrote:
(I am asking because I needed to jump through quite some hoops to build ansible for SLES15 with python3.10 from the Python3 module. If this macro makes it easier to do so I would be interested...)
Possibly it will make it easier, but for python 3.11.
I'll take what is avaiable in the Python3 module. :-)
We're building a reduced list of basic python packages, the modern version, just directly from Tumbleweed, to provide it in SLE15-SP4, so it should be available, but just in the python module.
Here you can find the devel project that we're using to build the list of packages and fix issues: https://build.opensuse.org/project/show/home:dirkmueller:acdc:as_python3_mod...
I've just updated the initial doc in the wiki, added by Robert, with a more detailed explanation: https://en.opensuse.org/openSUSE:Packaging_Python#Python_3_(Leap_Future)
1. Currently I set those lines in the prjconf in the SLES15+Python3 projects: ``` %define pythons python310 Macros: %pythons python310 :Macros ```
IIUC I can just remove this, once the macro was added to each package?
That's exactly what the macro does (but with python311), so you'll be able to remove it from your prconf and just use the macro when it's available.
2. Currently I hardcode the versions for Tumbleweed and SLES15 in e.g. the ansible-core spec file:
``` %if 0%{?suse_version} < 1550 # Leap15, SLES15 %define pythons python310 %define ansible_python python310 %define ansible_python_executable python3.10 %define ansible_python_sitelib %python310_sitelib %else # Tumbleweed %define pythons python3 %define ansible_python python3 %define ansible_python_executable python3 %define ansible_python_sitelib %python3_sitelib %endif ```
I assume that this needs to be adapted to 3.11 (and possibly other versions in the future?)?
This should be adapted, but in this case you'll need to continue modifying the pythons for tumbleweed to build just for the primary python, and setting the corresponding so at the end I don't see any difference if using the new macro or not, because this package doesn't use %python_subpackages -- Daniel García Moreno Python Packager
On 02.05.23 at 13:11 Daniel Garcia wrote:
On mar, 2023-05-02 at 12:48 +0200, Johannes Kastl wrote:
1. Currently I set those lines in the prjconf in the SLES15+Python3 projects: ``` %define pythons python310 Macros: %pythons python310 :Macros ```
IIUC I can just remove this, once the macro was added to each package?
That's exactly what the macro does (but with python311), so you'll be able to remove it from your prconf and just use the macro when it's available.
Hm, as this is set in the package, it seems it overwrites what I have in the project's prjconf. So my whole build chain using python3.10 is now switched to 3.11... :-( But as I wanted to rebuild this properly in systemsmanagement:ansible:SLE15 anyway, I'll start there using the new 3.11 stack.
This should be adapted, but in this case you'll need to continue modifying the pythons for tumbleweed to build just for the primary python, and setting the corresponding so at the end I don't see any difference if using the new macro or not, because this package doesn't use %python_subpackages
Will the new python3.11 stack for SLE15 stay with 3.11? Or will it switch to something else (perhaps regularly)? Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Hi Johannes On vie, 2023-05-05 at 06:55 +0200, Johannes Kastl wrote:
On 02.05.23 at 13:11 Daniel Garcia wrote:
On mar, 2023-05-02 at 12:48 +0200, Johannes Kastl wrote:
1. Currently I set those lines in the prjconf in the SLES15+Python3 projects: ``` %define pythons python310 Macros: %pythons python310 :Macros ```
IIUC I can just remove this, once the macro was added to each package?
That's exactly what the macro does (but with python311), so you'll be able to remove it from your prconf and just use the macro when it's available.
Hm, as this is set in the package, it seems it overwrites what I have in the project's prjconf. So my whole build chain using python3.10 is now switched to 3.11... :-(
But as I wanted to rebuild this properly in systemsmanagement:ansible:SLE15 anyway, I'll start there using the new 3.11 stack.
This should be adapted, but in this case you'll need to continue modifying the pythons for tumbleweed to build just for the primary python, and setting the corresponding so at the end I don't see any difference if using the new macro or not, because this package doesn't use %python_subpackages
Will the new python3.11 stack for SLE15 stay with 3.11? Or will it switch to something else (perhaps regularly)?
The new python 3.11 stack will stay with 3.11, at least until 3.11 EOL. There's no plan to add anything newer in the near future, even the python modules will be kept in the initial released version as much as possible. We don't plan to update this stack regularly, just provide a more recent stack and keep it stable, so people can use it and build things on top. We're doing the work thinking about the possibility of adding another python version in the future, so Python 3.12 could be possible, but there's no plan to do it right now, or in the future if there's no a hard requirement or a really good reason because, in other case, there will be more packages / versions to maintain. -- Daniel García Moreno Python Packager
Good morning Daniel, On 08.05.23 at 08:47 Daniel Garcia wrote:
The new python 3.11 stack will stay with 3.11, at least until 3.11 EOL. There's no plan to add anything newer in the near future, even the python modules will be kept in the initial released version as much as possible. We don't plan to update this stack regularly, just provide a more recent stack and keep it stable, so people can use it and build things on top.
Thanks for the information! Sounds good.
We're doing the work thinking about the possibility of adding another python version in the future, so Python 3.12 could be possible, but there's no plan to do it right now, or in the future if there's no a hard requirement or a really good reason because, in other case, there will be more packages / versions to maintain.
Sounds good, too! Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Am Dienstag, 25. April 2023, 09:20:33 CEST schrieb Daniel Garcia:
On mar, 2023-04-25 at 08:32 +0200, Eric Schirra wrote:
I see more and more %{?sle15_python_module_pythons} and %{sle15modernpython} in packages changes.
But i can't find any documentation about it. Not in wiki and not in python-rpm-macro.
So what's the deal with "%{?sle15_python_module_pythons}" ? And what's the deal with "%{sle15modernpython}" ?
This is related to SLE, we are trying to make the changes in factory to do not have different sources for the modern python packages provided there.
This macro won't do anything in Tumbleweed or other versions where it's not defined and in SLE it's just to set the "pythons" macro to a different value, so the multibuild can produce python3.11 packages there.
The final macro name is the first one, "%{?sle15_python_module_pythons}", the second one is a devel name and if it's in some devel package or Factory should be renamed to the other one.
Thank you very much for your answer. Two more questions. 1. do I understand it right, as long as the macro is not defined in python- rpm-macros it will not be executed in tumbleweed or leap? 2. is this still described somewhere in the wiki? Regards Eric
On 4/26/23 08:07, Eric Schirra wrote:
Am Dienstag, 25. April 2023, 09:20:33 CEST schrieb Daniel Garcia:
On mar, 2023-04-25 at 08:32 +0200, Eric Schirra wrote:
I see more and more %{?sle15_python_module_pythons} and %{sle15modernpython} in packages changes.
But i can't find any documentation about it. Not in wiki and not in python-rpm-macro.
So what's the deal with "%{?sle15_python_module_pythons}" ? And what's the deal with "%{sle15modernpython}" ?
This is related to SLE, we are trying to make the changes in factory to do not have different sources for the modern python packages provided there.
This macro won't do anything in Tumbleweed or other versions where it's not defined and in SLE it's just to set the "pythons" macro to a different value, so the multibuild can produce python3.11 packages there.
The final macro name is the first one, "%{?sle15_python_module_pythons}", the second one is a devel name and if it's in some devel package or Factory should be renamed to the other one.
Thank you very much for your answer. Two more questions. 1. do I understand it right, as long as the macro is not defined in python- rpm-macros it will not be executed in tumbleweed or leap?
The definition will come from the project config, not from the python-rpm-macros package. It will not be set in TW. The leap setting will be inherited from SLE which will set this to using 3.6 and 3.11. The effect is that every package that has %{?sle15_python_module_pythons} will build against Python 3.6 and python 3.11
2. is this still described somewhere in the wiki?
I added """ ==== Python 3 (Leap Future) ==== Leap has 2 Python interpreters, inherited from SLE, Python 3.6 and Python 3.11. To build modules with both interpreters use * <code>%{?sle15_python_module_pythons}</code> The macro is defined in the project setup in OBS. ----- """ Not all the pieces are in place yet, Matej, Dirk and others are still doing a lot of legwork to make this all come together. Later, Robert
Regards Eric
-- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Engineer LINUX Technical Team Lead Public Cloud rjschwei@suse.com IRC: robjo
On mié, 2023-04-26 at 08:22 -0400, Robert Schweikert wrote:
On 4/26/23 08:07, Eric Schirra wrote:
Am Dienstag, 25. April 2023, 09:20:33 CEST schrieb Daniel Garcia:
On mar, 2023-04-25 at 08:32 +0200, Eric Schirra wrote:
I see more and more %{?sle15_python_module_pythons} and %{sle15modernpython} in packages changes.
But i can't find any documentation about it. Not in wiki and not in python-rpm-macro.
So what's the deal with "%{?sle15_python_module_pythons}" ? And what's the deal with "%{sle15modernpython}" ?
This is related to SLE, we are trying to make the changes in factory to do not have different sources for the modern python packages provided there.
This macro won't do anything in Tumbleweed or other versions where it's not defined and in SLE it's just to set the "pythons" macro to a different value, so the multibuild can produce python3.11 packages there.
The final macro name is the first one, "%{?sle15_python_module_pythons}", the second one is a devel name and if it's in some devel package or Factory should be renamed to the other one.
Thank you very much for your answer. Two more questions. 1. do I understand it right, as long as the macro is not defined in python- rpm-macros it will not be executed in tumbleweed or leap?
The definition will come from the project config, not from the python-rpm-macros package. It will not be set in TW. The leap setting will be inherited from SLE which will set this to using 3.6 and 3.11.
The effect is that every package that has
%{?sle15_python_module_pythons}
will build against Python 3.6 and python 3.11
It's not exactly like that, just a bit different. These packages will just build for the modern python, that will be python 3.11. The python 3.6 version will be built from a different source package, that's the current one existing in SLE. All new python packages that we're planning to add will build with the latest version of python. Our test project has this macro: %sle15_python_module_pythons() %global pythons python311 The idea is to provide a modern version of a reduced list of python packages and build this list with python 3.11. So python 3.6 will continue as is, with it's python packages and old versions and there will be a modern version of some packages that will work with python 3.11.
2. is this still described somewhere in the wiki?
I added
""" ==== Python 3 (Leap Future) ==== Leap has 2 Python interpreters, inherited from SLE, Python 3.6 and Python 3.11. To build modules with both interpreters use
* <code>%{?sle15_python_module_pythons}</code>
The macro is defined in the project setup in OBS. ----- """
Not all the pieces are in place yet, Matej, Dirk and others are still doing a lot of legwork to make this all come together.
Thanks for the doc update. -- Daniel García Moreno Python Packager
On 2023-04-26 17:34, Daniel Garcia wrote:
Our test project has this macro:
%sle15_python_module_pythons() %global pythons python311
The idea is to provide a modern version of a reduced list of python packages and build this list with python 3.11.
Sorry if a join late and misinformed. I saw the PRs of this macro and I think that now I grasp the goal. IIUC the same python module (same version, same source code) will be compiled for 36 and 311 if this macro is present, making is a kind of a marker or flag. If this is correct, I wonder if polluting hundreds of Factory packages with this macro (that is nil for Tumbleweed) was the correct technical approach, and that the same goal could be achieved via some OBS/IBS work, where a subproject links the same list of packages (but with a project config that set the python to 3.11), and a later _aggregate somehow collect them into the main distribution.
On mié, 2023-04-26 at 17:50 +0200, aplanas wrote:
On 2023-04-26 17:34, Daniel Garcia wrote:
Our test project has this macro:
%sle15_python_module_pythons() %global pythons python311
The idea is to provide a modern version of a reduced list of python packages and build this list with python 3.11.
Sorry if a join late and misinformed. I saw the PRs of this macro and I think that now I grasp the goal. IIUC the same python module (same version, same source code) will be compiled for 36 and 311 if this macro is present, making is a kind of a marker or flag.
If this is correct, I wonder if polluting hundreds of Factory packages with this macro (that is nil for Tumbleweed) was the correct technical approach, and that the same goal could be achieved via some OBS/IBS work, where a subproject links the same list of packages (but with a project config that set the python to 3.11), and a later _aggregate somehow collect them into the main distribution.
This is nil for Tumbleweed, but will be useful in Leap, when building packages for a modern python version, the same way we're trying to do in SLE15-SP4. The main reason we submitted this to factory (other than "factory first policy") is that we've the project devel:languages:python:backports and we would like to make that project more useful than it is today. It currently has thousands of unresolvables with no chance of making it green as almost everything has dropped 3.6 support. Regards. -- Daniel García Moreno Python Packager
Am Mittwoch, 26. April 2023, 14:22:36 CEST schrieb Robert Schweikert:
On 4/26/23 08:07, Eric Schirra wrote:
Am Dienstag, 25. April 2023, 09:20:33 CEST schrieb Daniel Garcia:
On mar, 2023-04-25 at 08:32 +0200, Eric Schirra wrote:
I see more and more %{?sle15_python_module_pythons} and %{sle15modernpython} in packages changes.
But i can't find any documentation about it. Not in wiki and not in python-rpm-macro.
So what's the deal with "%{?sle15_python_module_pythons}" ? And what's the deal with "%{sle15modernpython}" ?
This is related to SLE, we are trying to make the changes in factory to do not have different sources for the modern python packages provided there.
This macro won't do anything in Tumbleweed or other versions where it's not defined and in SLE it's just to set the "pythons" macro to a different value, so the multibuild can produce python3.11 packages there.
The final macro name is the first one, "%{?sle15_python_module_pythons}", the second one is a devel name and if it's in some devel package or Factory should be renamed to the other one.
Thank you very much for your answer. Two more questions. 1. do I understand it right, as long as the macro is not defined in python- rpm-macros it will not be executed in tumbleweed or leap?
The definition will come from the project config, not from the python-rpm-macros package. It will not be set in TW. The leap setting will be inherited from SLE which will set this to using 3.6 and 3.11.
The effect is that every package that has
%{?sle15_python_module_pythons}
will build against Python 3.6 and python 3.11
2. is this still described somewhere in the wiki?
I added
""" ==== Python 3 (Leap Future) ==== Leap has 2 Python interpreters, inherited from SLE, Python 3.6 and Python 3.11. To build modules with both interpreters use
* <code>%{?sle15_python_module_pythons}</code>
The macro is defined in the project setup in OBS. ----- """
Not all the pieces are in place yet, Matej, Dirk and others are still doing a lot of legwork to make this all come together.
Super. Thank you to you and Daniel for the explanation. This makes it fun to work together. :-) Regards Eric
Am Dienstag, 25. April 2023, 09:20:33 CEST schrieb Daniel Garcia:
On mar, 2023-04-25 at 08:32 +0200, Eric Schirra wrote:
I see more and more %{?sle15_python_module_pythons} and %{sle15modernpython} in packages changes.
But i can't find any documentation about it. Not in wiki and not in python-rpm-macro.
So what's the deal with "%{?sle15_python_module_pythons}" ? And what's the deal with "%{sle15modernpython}" ?
This is related to SLE, we are trying to make the changes in factory to do not have different sources for the modern python packages provided there.
Hello Daniel, you wrote:
This macro won't do anything in Tumbleweed or other versions where it's not defined and in SLE it's just to set the "pythons" macro to a different value, so the multibuild can produce python3.11 packages there.
and Robert wrote: "The definition will come from the project config, not from the python-rpm-macros package. " I have not defined %{?sle15_python_module_pythons} anywhere in the project_configs. But since a few days every package which has %{?sle15_python_module_pythons} in its spec can't be built anymore. It always comes with Leap 15.4 similar "unresolvable: nothing provides python311-setuptools". Packages without %{?sle15_python_module_pythons} are built. It is also reproducible. If I remove %{?sle15_python_module_pythons} from the packages, they are built again. My questions now: What changed after your announcement? Why does it suddenly want to build 3.11 package although not defined anywhere? Why is %{?sle15_python_module_pythons} observed now? Where is the problem or error? Can someone help me? Regards Eric
Sorry. I forgot something else. In my meta it says: <path project="openSUSE:Leap:15.5:Update" repository="default"/> I now add behind it still <path project="openSUSE:Leap:15.5" repository="standard"/>, then build the python packages again, but obs does not recognize then, the newer packages in update. For example, in Update sqlite3 is in version 3.39. The build of the packages then recognizes but only da old in version 3.36. What is it now with all this aufich? Am I making some kind of mistake? But I was once told I should have only <path project="openSUSE:Leap: 15.5:Update" repository="standard"/> in the meta-data. Regards Eric
Just now I see that with 15.5 only 3.11 packages are built. And something else strange. Online with 15.4 the error message comes up as stated regarding 3.11. Offline with osc, however, the package builds without a hitch. As python3. And for 15.5 no 3.11 package is built offline, but a normal python3 as it should. What's going on there?
Now it's me again. Sorry if it is annoying. Using the GUI of the web browser I can't find an entry in ProjectConfig with %sle15_python_module_pythons(). But if I use "osc buildconfig home:ecsos 15.4" to display the ProjectConfig there appears: #request by slemke/dmueller 2023-05-04 for python311 builds. macros: # Macro to build Python stack proposal packages %sle15_python_module_pythons() %global pythons python311 :macros Why is that in there? According to your previous explanation, this is also observed in the specs and thus python311 is built. (But also only 311. Nothing else) Surely this should not be? Or is that now nevertheless firmly everywhere in it? Does he think that is a mistake? Why? How do I get the way? I do not see him online. Or can you take care of it and correct it? Regards Eric
Hi Eric, On sáb, 2023-05-06 at 11:27 +0200, Eric Schirra wrote:
Now it's me again. Sorry if it is annoying.
Using the GUI of the web browser I can't find an entry in ProjectConfig with %sle15_python_module_pythons().
But if I use "osc buildconfig home:ecsos 15.4" to display the ProjectConfig there appears:
#request by slemke/dmueller 2023-05-04 for python311 builds. macros: # Macro to build Python stack proposal packages %sle15_python_module_pythons() %global pythons python311 :macros
Why is that in there? According to your previous explanation, this is also observed in the specs and thus python311 is built. (But also only 311. Nothing else) Surely this should not be? Or is that now nevertheless firmly everywhere in it? Does he think that is a mistake? Why? How do I get the way? I do not see him online. Or can you take care of it and correct it?
The macro is now defined in the SUSE:SLE-15-SP4:Update project, so any project that derives from that will have the macro defined. The idea of that macro is to use it to build a reduced list of python packages for a modern python version (python 3.11), but the default Python (%primary_python) will continue to be the same, python 3.6. We will rename the source packages to build the Python 3.6 package version, so packages with name python3-foo will produce python3-foo.rpm binaries and packages with name python-foo will produce python311-foo.rpm. The second ones are the only that will have the new macro, the python3-foo kind of packages shouldn't have the new macro because they will continue using the default python defined in the project. So to make it more clear, if a spec file have the sle15_python_module_pythons macro, it's because that package will be built with the modern python version (Python 3.11). The python311, python311-pip and python311-setuptools packages are going to land in SP4 (and therefore in SP5) soon, and when we've that, packages with the new macro will build correctly in different projects, like devel:languages:python:backports. Indeed, pip and setuptools will be built using the new macro. I hope that this explanation helps to understand better what we're trying to do and what's happening right now (we added the macro to be able to build packages, but packages are not there yet, under review). Regards -- Daniel García Moreno Python Packager
Am Montag, 8. Mai 2023, 08:36:28 CEST schrieb Daniel Garcia:
Hi Eric,
On sáb, 2023-05-06 at 11:27 +0200, Eric Schirra wrote:
Now it's me again. Sorry if it is annoying.
Using the GUI of the web browser I can't find an entry in ProjectConfig with %sle15_python_module_pythons().
But if I use "osc buildconfig home:ecsos 15.4" to display the ProjectConfig there appears:
#request by slemke/dmueller 2023-05-04 for python311 builds. macros: # Macro to build Python stack proposal packages %sle15_python_module_pythons() %global pythons python311
:macros
Why is that in there? According to your previous explanation, this is also observed in the specs and thus python311 is built. (But also only 311. Nothing else) Surely this should not be? Or is that now nevertheless firmly everywhere in it? Does he think that is a mistake? Why? How do I get the way? I do not see him online. Or can you take care of it and correct it?
The macro is now defined in the SUSE:SLE-15-SP4:Update project, so any project that derives from that will have the macro defined.
The idea of that macro is to use it to build a reduced list of python packages for a modern python version (python 3.11), but the default Python (%primary_python) will continue to be the same, python 3.6.
We will rename the source packages to build the Python 3.6 package version, so packages with name python3-foo will produce python3-foo.rpm binaries and packages with name python-foo will produce python311-foo.rpm. The second ones are the only that will have the new macro, the python3-foo kind of packages shouldn't have the new macro because they will continue using the default python defined in the project.
So to make it more clear, if a spec file have the sle15_python_module_pythons macro, it's because that package will be built with the modern python version (Python 3.11).
The python311, python311-pip and python311-setuptools packages are going to land in SP4 (and therefore in SP5) soon, and when we've that, packages with the new macro will build correctly in different projects, like devel:languages:python:backports. Indeed, pip and setuptools will be built using the new macro.
I hope that this explanation helps to understand better what we're trying to do and what's happening right now (we added the macro to be able to build packages, but packages are not there yet, under review).
I thought existing projects were not being attacked? So it was communicated here. But that has now happened with this. There are now no more branched packages built in the home project which contain the macro. And that is so intentional? If now the objection should come, I should enter only standard in the meta, so this does not work either. Because some packages are in update and also mandatory. And why should I also build against old package, if these are meanwhile newer. Would say, that would be then even a mistake. The second is that there are no python311 packages under Leap. So the whole thing cannot work at all. And all packages in Leap are called python- and not python3-. In my opinion this is a total mess even though I like the idea behind it. Only the implementation... Why is not simply the old 3.6 left and only additionally added e.g. 3.11? As it practically Tumblweeed also does? And then all existing python packages also built for python 311. Additionally. Then everyone can take the version he wants and he could possibly switch all his packages to 311. If he wants. And if this macros would be able to build both, that would work too. But like this? So now again my question. What do I have to do if I want to build packages for Leap 15.4? Since phython311 packages bring me nothing at all, because there is no python311 and secondly all other python packages that I need for my package are 3.6 packages. And i probably need packages from devel from time to time. Or if I want to update an existing python program. Then python 3.11 brings me nothing. I have now helped me that I have changed the macro in my ProjectConfig back to python3. But this can't be the solution. Or is it? Regards Eric
Eric Schirra wrote:
The second is that there are no python311 packages under Leap. So the whole thing cannot work at all.
They're in progress of being added to Leap, however that comes via maintenance and will take time.
And all packages in Leap are called python- and not python3-.
And that's okay. you can keep it that way *unless* you want to update to 3.11. The rename to python3 is only needed if you have two different source versions (one for 3.6 and one for 3.11). if you can build for both or only build for python3 no work is needed.
Why is not simply the old 3.6 left and only additionally added e.g. 3.11?
Thats what we're doing
As it practically Tumblweeed also does?
Because Tumbleweed and Leap are different release models, we need to cater both.
And then all existing python packages also built for python 311. Additionally. Then everyone can take the version he wants and he could possibly switch all his packages to 311. If he wants.
That is the plan. Just that practically there is less than 0.5% of packages that build with the same source for python 3.6 and python 3.11 at the same time, the "tumbleweed model" does not work for Leap.
Since phython311 packages bring me nothing at all, because there is no python311 and secondly all other python packages that I need for my package are 3.6 packages.
then build for 3.6. Greetings, Dirk
Am Montag, 8. Mai 2023, 11:47:07 CEST schrieb Dirk Mueller:
Eric Schirra wrote:
The second is that there are no python311 packages under Leap. So the whole thing cannot work at all. They're in progress of being added to Leap, however that comes via maintenance and will take time. And all packages in Leap are called python- and not python3-.
And that's okay. you can keep it that way *unless* you want to update to 3.11. The rename to python3 is only needed if you have two different source versions (one for 3.6 and one for 3.11). if you can build for both or only build for python3 no work is needed.
then build for 3.6.
I would like to keep it that way. But exactly that this no longer works, I try to show here. That's because for a few days no longer works. Since a few days the new macro has been inserted in the non-public part, which is not visible for me via the GUI. And this although it was said, exactly this would not happen. Thus, the packages in my HomeRepo, just built with python311. As far as it would go. "Normal" python 3.6 packages are no longer built at all. Since I can not change the "non-public part", I do not know how to describe it, I helped myself with a crutch. I now add in my part of the ProjectConfig that I can change the following: macros: %sle15_python_module_pythons() %global pythons python3 :macros Because only then the packages which have the above macro in their specfile will be built at all. And they will be built suitable for Leap 15.4. Also I tried to show that a pure: <path project="openSUSE:Leap:15.4" repository="standard"/> in the meta data can't be the solution either. Once because there are important innovations in the updates and secondly because I can not really check whether the packages fit together via huapt. So I have to have the following in my meta forcibly: <path project="openSUSE:Leap:15.4:Update" repository="standard"/> I hope I could clarify my problem/concern now. And I hope there is now a solution for it. I can't imagine that I'm the only one with this problem. Regards Eric
On 5/8/23 15:07, Eric Schirra wrote:
Am Montag, 8. Mai 2023, 11:47:07 CEST schrieb Dirk Mueller:
Eric Schirra wrote:
The second is that there are no python311 packages under Leap. So the whole thing cannot work at all. They're in progress of being added to Leap, however that comes via maintenance and will take time. And all packages in Leap are called python- and not python3-.
And that's okay. you can keep it that way *unless* you want to update to 3.11. The rename to python3 is only needed if you have two different source versions (one for 3.6 and one for 3.11). if you can build for both or only build for python3 no work is needed.
then build for 3.6.
I would like to keep it that way.
But exactly that this no longer works, I try to show here.
That's because for a few days no longer works. Since a few days the new macro has been inserted in the non-public part, which is not visible for me via the GUI. And this although it was said, exactly this would not happen.
Thus, the packages in my HomeRepo, just built with python311. As far as it would go. "Normal" python 3.6 packages are no longer built at all.
Since I can not change the "non-public part", I do not know how to describe it, I helped myself with a crutch.
I now add in my part of the ProjectConfig that I can change the following:
macros: %sle15_python_module_pythons() %global pythons python3 :macros
Because only then the packages which have the above macro in their specfile will be built at all. And they will be built suitable for Leap 15.4.
Also I tried to show that a pure: <path project="openSUSE:Leap:15.4" repository="standard"/>
in the meta data can't be the solution either. Once because there are important innovations in the updates and secondly because I can not really check whether the packages fit together via huapt.
So I have to have the following in my meta forcibly: <path project="openSUSE:Leap:15.4:Update" repository="standard"/>
I hope I could clarify my problem/concern now. And I hope there is now a solution for it. I can't imagine that I'm the only one with this problem.
You are not. Devel packages for Leap 15.4 are not building since a while now, requiring me to branch them and redefine %pythons myself to get the 3.6 version to build again. I'm all for the new Python stack but I wonder if there's a better way to build it than having the working 3.6 packages break during the process.
Regards Eric
Am Montag, 8. Mai 2023, 15:17:22 CEST schrieb Georg Pfuetzenreuter:
On 5/8/23 15:07, Eric Schirra wrote:
Am Montag, 8. Mai 2023, 11:47:07 CEST schrieb Dirk Mueller:
Eric Schirra wrote:
The second is that there are no python311 packages under Leap. So the whole thing cannot work at all.
They're in progress of being added to Leap, however that comes via maintenance and will take time.
And all packages in Leap are called python- and not python3-.
And that's okay. you can keep it that way *unless* you want to update to 3.11. The rename to python3 is only needed if you have two different source versions (one for 3.6 and one for 3.11). if you can build for both or only build for python3 no work is needed.
then build for 3.6.
I would like to keep it that way.
But exactly that this no longer works, I try to show here.
That's because for a few days no longer works. Since a few days the new macro has been inserted in the non-public part, which is not visible for me via the GUI. And this although it was said, exactly this would not happen.
Thus, the packages in my HomeRepo, just built with python311. As far as it would go. "Normal" python 3.6 packages are no longer built at all.
Since I can not change the "non-public part", I do not know how to describe it, I helped myself with a crutch.
I now add in my part of the ProjectConfig that I can change the following:
macros: %sle15_python_module_pythons() %global pythons python3
:macros
Because only then the packages which have the above macro in their specfile will be built at all. And they will be built suitable for Leap 15.4.
Also I tried to show that a pure: <path project="openSUSE:Leap:15.4" repository="standard"/>
in the meta data can't be the solution either. Once because there are important innovations in the updates and secondly because I can not really check whether the packages fit together via huapt.
So I have to have the following in my meta forcibly: <path project="openSUSE:Leap:15.4:Update" repository="standard"/>
I hope I could clarify my problem/concern now. And I hope there is now a solution for it. I can't imagine that I'm the only one with this problem.
You are not. Devel packages for Leap 15.4 are not building since a while now, requiring me to branch them and redefine %pythons myself to get the 3.6 version to build again. I'm all for the new Python stack but I wonder if there's a better way to build it than having the working 3.6 packages break during the process.
That is exactly what I mean and what I am pointing out. That the packages in devel:languages:python can no longer be built is clear to me. But I could always take the last version compatible with python 3.6 if it was already too old in Leap itself. And exactly that is no longer possible. Unless I add my crutch to the ProjectConfig. And that just since a few days, since just the new macros became active everywhere. :-( Regards Eric
participants (7)
-
aplanas -
Daniel Garcia -
Dirk Mueller -
Eric Schirra -
Georg Pfuetzenreuter -
Johannes Kastl -
Robert Schweikert