Todd Rme píše v Út 23. 07. 2019 v 15:22 -0400:

Current we have Tornado 4 in openSUSE, but it has been unmaintained for more than a year and a half, which is worrisome for a web-facing framework like Tornado. Tornado 5 was released March 2018 and Tornado 6, the current version, was released March 2019.

Unforunately some packages have been slow to update, but we are reaching the point where packages are beginning to drop support for Tornado 4. This leads to a situation where certain packages cannot be installed at the same time.

Should we be using versioned releases of Tornado like we started doing for pytest?

Good question. Your assesment bellow this quite spot on, but keeping it out for readability. The biggest issue is that tornado4 does not work at all with python 3.8 so one I suppose we should start branching it if it is pain (esp. as the pytest is major pain in the butt and upstream does not care that most devs just write pytest==3.whatever and are done with it). If the attitude is the same for tornado we should 'multiversion' it as well. If we have chance to leverage the upstreams to fix for latest versions tho it is much much better solution (from your list most of them are supporting 5 so we should shoot for it). Last time the ONLY blocker we had in distro for tornado5 was saltstack and honestly it took a bit to get it rolling with py3.7 and this time I would rather just sack it. Cheers Tom BTW unrelated: could you please list all the new added python2-* packages for the clouders here? Something like the email from me, nothing shiny.

Todd Rme píše v Ne 28. 07. 2019 v 23:06 -0400:

On Tue, Jul 23, 2019 at 3:40 PM Tomas Chvatal wrote:

...

Todd Rme píše v Út 23. 07. 2019 v 15:22 -0400:

...

Current we have Tornado 4 in openSUSE, but it has been unmaintained for more than a year and a half, which is worrisome for a web- facing framework like Tornado. Tornado 5 was released March 2018 and Tornado 6, the current version, was released March 2019.

Unforunately some packages have been slow to update, but we are reaching the point where packages are beginning to drop support for Tornado 4. This leads to a situation where certain packages cannot be installed at the same time.

Should we be using versioned releases of Tornado like we started doing for pytest?

Good question. Your assesment bellow this quite spot on, but keeping it out for readability.

The biggest issue is that tornado4 does not work at all with python 3.8 so one I suppose we should start branching it if it is pain (esp. as the pytest is major pain in the butt and upstream does not care that most devs just write pytest==3.whatever and are done with it).

If the attitude is the same for tornado we should 'multiversion' it as well. If we have chance to leverage the upstreams to fix for latest versions tho it is much much better solution (from your list most of them are supporting 5 so we should shoot for it).

Last time the ONLY blocker we had in distro for tornado5 was saltstack and honestly it took a bit to get it rolling with py3.7 and this time I would rather just sack it.

Cheers

Tom

So there seems to be no objections to this. What would be the best way to proceed? I assume we will have 3 versions, python-tornado4, python-tornad5, and python-tornad6? If so, I see a few ways to proceed:

1. Have a "python-tornado" dummy package that pull in the preferred version, probably python-tornado5. Packages that can't use that (or can only use 5) can specify a version number. 2. Have the preferred version (again probably 5) provide python-tornado, and again let packages that need to specify the version 3. Have all three packages provide "python-tornado", let packages specify which version range they can handle, and let zypper's dependency handler work out what to do. 4. Have nothing provide "python-tornado", have all packages specify which combination they support using the new "or" operator, and again let zypper figure out what to install.

Anyone have any thoughts? I would lean towards 1 myself, since it provides a cleaner update path. Even if zypper's dependency solver works perfectly, it could be confusing to people to get a major downgrade (6 to 5, for example) when installing a new package. Anyone have any thoughts?

Well one note is that we can't keep tornado3, we are already prepping the 3.8 that won't work with it anyway so I would absolutely ignore that one. For the options above option 1 and 3 sound the most pleasing. The difference being that for option 3 you need prjconf adjustment and do not need metapackage. I try to avoid metapackages and stick with prjconf but both of the solutions achieve the same results for zypper. Cheers Tom

Does anyone have any thoughts on this? This is holding up some major updates so I would like to get moving on it as soon as possible. On Mon, Jul 29, 2019 at 1:44 PM Todd Rme wrote:

I have submitted python-tornado4 [1], python-tornado5 [2], and python-tornado6 [3] packages. I know python-tornado4 won't work for that much longer, but it is enabled for backwards-compatibility and older openSUSE releases for now. I have also updated the devel:languages:python project config to prefer python-tornado5.

[1] https://build.opensuse.org/request/show/719688 [2] https://build.opensuse.org/request/show/719689 [3] https://build.opensuse.org/request/show/719696

On Mon, Jul 29, 2019 at 5:13 AM Tomas Chvatal wrote:

...

Todd Rme píše v Ne 28. 07. 2019 v 23:06 -0400:

...

On Tue, Jul 23, 2019 at 3:40 PM Tomas Chvatal wrote:

...

Todd Rme píše v Út 23. 07. 2019 v 15:22 -0400:

...

Current we have Tornado 4 in openSUSE, but it has been unmaintained for more than a year and a half, which is worrisome for a web- facing framework like Tornado. Tornado 5 was released March 2018 and Tornado 6, the current version, was released March 2019.

Unforunately some packages have been slow to update, but we are reaching the point where packages are beginning to drop support for Tornado 4. This leads to a situation where certain packages cannot be installed at the same time.

Should we be using versioned releases of Tornado like we started doing for pytest?

Good question. Your assesment bellow this quite spot on, but keeping it out for readability.

The biggest issue is that tornado4 does not work at all with python 3.8 so one I suppose we should start branching it if it is pain (esp. as the pytest is major pain in the butt and upstream does not care that most devs just write pytest==3.whatever and are done with it).

If the attitude is the same for tornado we should 'multiversion' it as well. If we have chance to leverage the upstreams to fix for latest versions tho it is much much better solution (from your list most of them are supporting 5 so we should shoot for it).

Last time the ONLY blocker we had in distro for tornado5 was saltstack and honestly it took a bit to get it rolling with py3.7 and this time I would rather just sack it.

Cheers

Tom

So there seems to be no objections to this. What would be the best way to proceed? I assume we will have 3 versions, python-tornado4, python-tornad5, and python-tornad6? If so, I see a few ways to proceed:

1. Have a "python-tornado" dummy package that pull in the preferred version, probably python-tornado5. Packages that can't use that (or can only use 5) can specify a version number. 2. Have the preferred version (again probably 5) provide python-tornado, and again let packages that need to specify the version 3. Have all three packages provide "python-tornado", let packages specify which version range they can handle, and let zypper's dependency handler work out what to do. 4. Have nothing provide "python-tornado", have all packages specify which combination they support using the new "or" operator, and again let zypper figure out what to install.

Anyone have any thoughts? I would lean towards 1 myself, since it provides a cleaner update path. Even if zypper's dependency solver works perfectly, it could be confusing to people to get a major downgrade (6 to 5, for example) when installing a new package. Anyone have any thoughts?

Well one note is that we can't keep tornado3, we are already prepping the 3.8 that won't work with it anyway so I would absolutely ignore that one.

For the options above option 1 and 3 sound the most pleasing. The difference being that for option 3 you need prjconf adjustment and do not need metapackage.

I try to avoid metapackages and stick with prjconf but both of the solutions achieve the same results for zypper.

Cheers

Tom

-- To unsubscribe, e-mail: opensuse-python+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-python+owner@opensuse.org

I have split the python-tornado packages into 3 version-specific packages in order to deal with the fact that some packages only support tornado 4 and others only tornado 5. openSUSE:Factory should be configured to prefer "python-tornado5", "python2-tornado5", and "python3-tornad5". The relevant submit requests are below: https://build.opensuse.org/request/show/721284 https://build.opensuse.org/request/show/721285 https://build.opensuse.org/request/show/721286 https://build.opensuse.org/request/show/721287 ---------- Forwarded message --------- From: Tomas Chvatal Date: Sun, Aug 4, 2019 at 3:09 PM Subject: Re: [opensuse-python] What to do about Tornado To: opensuse-python@opensuse.org LGTM. Honestly I would test it in the staging and if it looks okay I would proceed. Just let know dimstar to set proper version as a default when it gets integrated. Cheers Tom Todd Rme píše v Ne 04. 08. 2019 v 14:25 -0400:

Does anyone have any thoughts on this? This is holding up some major updates so I would like to get moving on it as soon as possible.

On Mon, Jul 29, 2019 at 1:44 PM Todd Rme wrote:

...

I have submitted python-tornado4 [1], python-tornado5 [2], and python-tornado6 [3] packages. I know python-tornado4 won't work for that much longer, but it is enabled for backwards-compatibility and older openSUSE releases for now. I have also updated the devel:languages:python project config to prefer python-tornado5.

[1] https://build.opensuse.org/request/show/719688 [2] https://build.opensuse.org/request/show/719689 [3] https://build.opensuse.org/request/show/719696

On Mon, Jul 29, 2019 at 5:13 AM Tomas Chvatal wrote:

...

Todd Rme píše v Ne 28. 07. 2019 v 23:06 -0400:

...

On Tue, Jul 23, 2019 at 3:40 PM Tomas Chvatal wrote:

...

Todd Rme píše v Út 23. 07. 2019 v 15:22 -0400:

...

Current we have Tornado 4 in openSUSE, but it has been unmaintained for more than a year and a half, which is worrisome for a web- facing framework like Tornado. Tornado 5 was released March 2018 and Tornado 6, the current version, was released March 2019.

Unforunately some packages have been slow to update, but we are reaching the point where packages are beginning to drop support for Tornado 4. This leads to a situation where certain packages cannot be installed at the same time.

Should we be using versioned releases of Tornado like we started doing for pytest?

Good question. Your assesment bellow this quite spot on, but keeping it out for readability.

The biggest issue is that tornado4 does not work at all with python 3.8 so one I suppose we should start branching it if it is pain (esp. as the pytest is major pain in the butt and upstream does not care that most devs just write pytest==3.whatever and are done with it).

If the attitude is the same for tornado we should 'multiversion' it as well. If we have chance to leverage the upstreams to fix for latest versions tho it is much much better solution (from your list most of them are supporting 5 so we should shoot for it).

Last time the ONLY blocker we had in distro for tornado5 was saltstack and honestly it took a bit to get it rolling with py3.7 and this time I would rather just sack it.

Cheers

Tom

So there seems to be no objections to this. What would be the best way to proceed? I assume we will have 3 versions, python- tornado4, python-tornad5, and python-tornad6? If so, I see a few ways to proceed:

1. Have a "python-tornado" dummy package that pull in the preferred version, probably python-tornado5. Packages that can't use that (or can only use 5) can specify a version number. 2. Have the preferred version (again probably 5) provide python-tornado, and again let packages that need to specify the version 3. Have all three packages provide "python-tornado", let packages specify which version range they can handle, and let zypper's dependency handler work out what to do. 4. Have nothing provide "python-tornado", have all packages specify which combination they support using the new "or" operator, and again let zypper figure out what to install.

Anyone have any thoughts? I would lean towards 1 myself, since it provides a cleaner update path. Even if zypper's dependency solver works perfectly, it could be confusing to people to get a major downgrade (6 to 5, for example) when installing a new package. Anyone have any thoughts?

Well one note is that we can't keep tornado3, we are already prepping the 3.8 that won't work with it anyway so I would absolutely ignore that one.

For the options above option 1 and 3 sound the most pleasing. The difference being that for option 3 you need prjconf adjustment and do not need metapackage.

I try to avoid metapackages and stick with prjconf but both of the solutions achieve the same results for zypper.

Cheers

Tom

-- To unsubscribe, e-mail: opensuse-python+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-python+owner@opensuse.org

On Tue, Aug 6, 2019 at 10:58 AM Dominique Leuenberger / DimStar wrote:

Hi Todd,

On Tue, 2019-08-06 at 10:45 -0400, Todd Rme wrote:

...

I have split the python-tornado packages into 3 version-specific packages in order to deal with the fact that some packages only support tornado 4 and others only tornado 5. openSUSE:Factory should be configured to prefer "python-tornado5", "python2-tornado5", and "python3-tornad5". The relevant submit requests are below:

https://build.opensuse.org/request/show/721284 https://build.opensuse.org/request/show/721285 https://build.opensuse.org/request/show/721286 https://build.opensuse.org/request/show/721287

The 'standard' way is to have the 'leading package' unversioned - and only add the compat ones with a version. So you'd get python-tornado (version 5 for now, until 6 comes out) plus python-tornado[34].

This would also bring with it that the Prefer: python[23]-tornado would for once and all be 'true' - and always refer tot he 'latest version'.

Cheers Dominique

Hi Dominique, We discussed that, but felt that that use prefers is better in this situation. There are two big issues in this case. First, we have a bunch of cross-distro packages that depend on tornado 4 (the salt testing stack) so changing the naming scheme would be break their cross-distro compatibility. Second, most packages support both tornado 4 and 5, any many support 4, 5, and 6. If we have those depend on tornado 5 specifically, then they can no longer be installed alongside packages that depend on tornado 4 only. This would artificially add a ton of conflicts for packages that depend on tornado 4 exclusively, greatly limiting how much they can be used. Best, Todd -- To unsubscribe, e-mail: opensuse-python+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-python+owner@opensuse.org

On Tue, Aug 6, 2019 at 12:19 PM Dominique Leuenberger / DimStar wrote:

On Tue, 2019-08-06 at 11:59 -0400, Todd Rme wrote:

...

On Tue, Aug 6, 2019 at 10:58 AM Dominique Leuenberger / DimStar wrote:

...

Hi Todd,

On Tue, 2019-08-06 at 10:45 -0400, Todd Rme wrote:

...

I have split the python-tornado packages into 3 version-specific packages in order to deal with the fact that some packages only support tornado 4 and others only tornado 5. openSUSE:Factory should be configured to prefer "python-tornado5", "python2-tornado5", and "python3-tornad5". The relevant submit requests are below:

https://build.opensuse.org/request/show/721284 https://build.opensuse.org/request/show/721285 https://build.opensuse.org/request/show/721286 https://build.opensuse.org/request/show/721287

The 'standard' way is to have the 'leading package' unversioned - and only add the compat ones with a version. So you'd get python-tornado (version 5 for now, until 6 comes out) plus python-tornado[34].

This would also bring with it that the Prefer: python[23]-tornado would for once and all be 'true' - and always refer tot he 'latest version'.

Cheers Dominique

Hi Dominique,

We discussed that, but felt that that use prefers is better in this situation. There are two big issues in this case.

First, we have a bunch of cross-distro packages that depend on tornado 4 (the salt testing stack) so changing the naming scheme would be break their cross-distro compatibility.

I think you misunderstood something: the 'Prefer' statement would still be in place, just for python[23]-Tornado (instead of python[23]- Tornado5. This is especially interesting as the config won't have to be changed with every major version coming out (i.e. Tornado 6)

...

Second, most packages support both tornado 4 and 5, any many support 4, 5, and 6. If we have those depend on tornado 5 specifically, then they can no longer be installed alongside packages that depend on tornado 4 only. This would artificially add a ton of conflicts for packages that depend on tornado 4 exclusively, greatly limiting how much they can be used.

There would be no difference: a package can require python-tornado > 4, which could be satisfied by Tornado 4, 5 and 6 (requiring that all python-tornadi<X> provide the symbol, but I'd assume that as a given anyway, otherwise no Prefer statement would be needed anyway).

As long as those packages can be installed alongside, then everything is good. and if they can't be installed alongside, then also having python-Tornado5 does not change that fact.

As for cross-distro: it would be even clearer - as the info about python-Tornado<x> would not have to be known at all.

I do not think I understand, then. Could you please explain what specific packages there should be and what each of them should do? Thanks -Todd -- To unsubscribe, e-mail: opensuse-python+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-python+owner@opensuse.org

On Wed, Aug 7, 2019 at 7:35 AM Dominique Leuenberger / DimStar wrote:

On Tue, 2019-08-06 at 16:31 -0400, Todd Rme wrote:

...

I do not think I understand, then. Could you please explain what specific packages there should be and what each of them should do? Thanks

options are many - from what I gather, the different tornado versions cannot coexist on a system thouhh (they all install to +%{python_sitearch}/tornado) - so in the end this will remain a disaster.

But gneerally, the thing you try to solve, is done like this:

3 packages: python-tornado (version <LATEST>.x) python-tornado5 (version 5.x) Provides: python-tornado = 5.x Conflicts: python-tornado python-tornado4 (version 4.x) Provides: python-tornado = 4.x Conflicts: python-tornado

Other packages then don't need to know at all what the names of the packages are, and can do:

Package FOO (works with tornado 5 and later): Requires: python-tornado >= x

Package BAR: works with Tornado 4 and 5, but not with 6: Requires: python-tornado >= 3.x Conflicts: python-tornado >= 6

And BAZ requires tornado 6 (or later - we don't know yet) Requires: python-tornado >= 6.x

Of course, BAZ and and BAR can't be installed next to each other, as BAR wold require a tornado < 6 - and none of them can be installed without conflicting with tornado 6.x.

So far clear I hope?

In the future, when we get tornado 7 in plus, python-tornado will be updated to version 7.x and python-tornado6 be introduced (thus, no version suffix always on the latest version)

The problem is that the package want to prefer is tornado 5, not tornado 6. tornado 6 just isn't widely supported right now. -- To unsubscribe, e-mail: opensuse-python+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-python+owner@opensuse.org

On Thu, Aug 8, 2019 at 2:44 AM Dominique Leuenberger / DimStar wrote:

On Wed, 2019-08-07 at 10:43 -0400, Todd Rme wrote:

...

The problem is that the package want to prefer is tornado 5, not tornado 6. tornado 6 just isn't widely supported right now.

I see; in this case I'd go the same route as go and ruby do then.. and you'd have packages like:

python-tornado4 Provides: python-tornado = 4.x Provides python-tornado-impl = 4.x Conflicts: python-tornado-impl python-tornado5 Provides: pytho-tornado = 5.x Provides python-tornado-impl = 5.x Conflicts: python-tornado-impl python-tornado6 Provides: python-tornado =6.x Provides python-tornado-impl = 6.x Conflicts: python-tornado-impl python-tornado Version 5.x Requires: python-tornado-impl = 5.x

Then when you feel it is time to switch from tornado 5.x to 6.x, you have the control in python-tornado and you can bump the version there.

Prjconf would prefer python-tornado.

Cheers, Dominique

But how would packages know to depend on python-tornado rather than any of the other packages that provide python-tornado? -- To unsubscribe, e-mail: opensuse-python+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-python+owner@opensuse.org

Hi, python-tornado broke now the cloud ci[1]: nothing provides python2-tornado-impl = 4.5.3 needed by python2-tornado I don't understand why the python-tornado package is now an empty package (instead of just packaging the latest version). Can't we have: - python-tornado (which is tornado6) - python-tornado5 (which is tornado5) - python-tornado4 (..) and if a package requires something different from the latest version, just adjust the Requires: there? That seems to be the way we go with python-pytest and I don't see a reason why to not follow that. Am I missing something here? Cheers, Tom [1] https://build.opensuse.org/package/show/home:suse-cloud-ci:rpm-packaging-sle... -- To unsubscribe, e-mail: opensuse-python+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-python+owner@opensuse.org

Hi, On 8/23/19 11:16 AM, Dominique Leuenberger / DimStar wrote:

On Fri, 2019-08-23 at 11:13 +0200, Thomas Bechtold wrote:

...

Hi,

python-tornado broke now the cloud ci[1]:

nothing provides python2-tornado-impl = 4.5.3 needed by python2-tornado

I don't understand why the python-tornado package is now an empty package (instead of just packaging the latest version).

Can't we have:

- python-tornado (which is tornado6) - python-tornado5 (which is tornado5) - python-tornado4 (..)

and if a package requires something different from the latest version, just adjust the Requires: there? That seems to be the way we go with python-pytest and I don't see a reason why to not follow that.

Am I missing something here?

That is one valid approach - and the tornado maintainer chose the 2nd on - same as is used by go, gcc and others.

They have a meta package which gives the 'preferred' version of a package for the distribution (non-suffixed) - and all the others, including the actual code to the meta package, as a suffixed package.

This seems more complicated then needed. We have now one extra package that we need to take care of. It might make more sense when you can co-install packages (like gcc7 and gcc8). Anyway - thanks for the explanation!

python-tornado4 with the correct version has been checked in to Factory the exact same moment as python-tornado requiring it.

Ok. devel:languages:python:backports (which links to openSUSE:Factory packages and is used for the CI) needed an update to get the new package. Thanks for the hint. Cheers, Tom -- To unsubscribe, e-mail: opensuse-python+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-python+owner@opensuse.org