> Same dependency on greenlet as the 64-bit architectures.

Sorry, the s390x architecture is affected and is 64-bit. This should have read “Same dependency on greenlet as the other architectures.”—that is, as x86_64, ppc64le, and aarch64.

agree, since this is based on packaging and you have greenlet for all platforms, SQLAlchemy's limiting req, which is based on what people can reasonably install with pip, should be skipped.

I would note you can explicitly install all asyncio dependencies using the `sqlalchemy[asyncio]` pip target.

We can of course patch this downstream, but that seems ugly. ;( 

Here's a scratch build with it commented: https://koji.fedoraproject.org/koji/taskinfo?taskID=77537004

I wish there was a better upstream solution here... Adding mhroncok in case he or the rest of the python team has some better solution here. :)

A better solution for what problem? If the package fails to function without greenlet, it should be required on all arches. Why does upstream do this thing? If they attempt not to depend on greenlet on architecture where greenlet is not available as a wheel on PyPI, does the package function without it?

(In reply to Miro Hrončok from comment #4)
> A better solution for what problem? If the package fails to function without
> greenlet, it should be required on all arches. Why does upstream do this
> thing? If they attempt not to depend on greenlet on architecture where
> greenlet is not available as a wheel on PyPI, does the package function
> without it?

yes, the package functions without it.  the greenlet dependency for SQLAlchemy is used only for the "asyncio" extension which is optional.  if you dont use the "asyncio" extension, you don't need greenlet.    this is why we had a lot of user complaints about the greenlet dependency, because the vast majority of users didn't need it, and those users who were running on platforms that don't have build tools installed and are on an architecture for which greenlet did not publish a wheel, they couldn't use the package.

optional dependencies are a completely normal Python feature as stated in pep508 https://www.python.org/dev/peps/pep-0508/#extras.  SQLAlchemy supplies an install target for this optional dependency using the "sqlalchemy[asyncio]" extra.

Overall im not too clear on what the downstream problem is here, you can add "greenlet" as a dependency to the spec file, or simply use the "sqlalchemy[asyncio]" target.  why do the setup requirements in the library itself need to be patched?

oh,  one more important thing.    Looking at the stack trace at the top:

# python3 -c 'import sqlalchemy.dialects.mysql'
> Traceback (most recent call last):
>   File "<string>", line 1, in <module>
>   File "/usr/lib/python3.10/site-packages/sqlalchemy/dialects/mysql/__init__.py", line 57, in <module>
>     from . import asyncmy  # noqa
>   File "/usr/lib/python3.10/site-packages/sqlalchemy/dialects/mysql/asyncmy.py", line 175, in <module>
>     class AsyncAdapt_asyncmy_connection(AdaptedConnection):
>   File "/usr/lib/python3.10/site-packages/sqlalchemy/dialects/mysql/asyncmy.py", line 185, in AsyncAdapt_asyncmy_connection
>     async def _mutex_and_adapt_errors(self):
>   File "/usr/lib/python3.10/site-packages/sqlalchemy/util/concurrency.py", line 63, in asynccontextmanager
>     _not_implemented()
>   File "/usr/lib/python3.10/site-packages/sqlalchemy/util/concurrency.py", line 37, in _not_implemented
>     raise ValueError(
> ValueError: the greenlet library is required to use this function.

OK that's our bug and that's fixed in 1.4.26: https://docs.sqlalchemy.org/en/14/changelog/changelog_14.html#change-ba4c0d15b376580f1123f7ac4374cbe9  https://github.com/sqlalchemy/sqlalchemy/issues/7204

so the specific problem here is also fixed in upstream.  sorry i missed that in the description.

> OK that's our bug and that's fixed in 1.4.26: https://docs.sqlalchemy.org/en/14/changelog/changelog_14.html#change-ba4c0d15b376580f1123f7ac4374cbe9  https://github.com/sqlalchemy/sqlalchemy/issues/7204

That’s what actually prompted me to file this issue. I’m happy to see a fix—thanks for pointing it out.

> Overall im not too clear on what the downstream problem is here, you can add "greenlet" as a dependency to the spec file, or simply use the "sqlalchemy[asyncio]" target.  why do the setup requirements in the library itself need to be patched?

Given that the failure to import sqlalchemy.dialects.mysql without greenlet is a separate issue, I agree that asking any projects that actually need the async functionality to require sqlalchemy[asyncio] is correct.

I still think that, as a Fedora user, the arch-dependent greenlet dependency is very surprising here. I expect that a distribution package will have different dependencies or different default-enabled functionality on different architectures only in cases where there is no other choice—due to an architecture build failure or a dependency that is inherently arch-specific.

However, I would still understand if the answer was, “it’s not actually broken, and we want to do exactly what upstream does.”

Since the package is arched, I'd do exactly what upstream does. If sqlalchemy was noarch, we would have a problem, but luckily it is not.


In upstream, I would not require greenlet on some arches, I would not require it at all -- I would leave that to the sqlalchemy[asyncio] extra. But that's not my battle to fight.

Ok! Sounds like there’s a consensus—I will go ahead and close this as NOTABUG. I appreciate everyone’s input.