-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Doesn't work with sqlalchemy 2 (2.0.30) #164
Comments
Same issue here. Cannot launch Gourmand anymore. I am afraid the project is no more maintained, as I don't see anything new since a long time. |
Migration is needed https://docs.sqlalchemy.org/en/20/changelog/migration_20.html |
@bkmgit Yes do you have a patch ? |
@marillat May take a bit of time. It runs with Sqlalchemy 1.4. For linux desktop, other alternatives are Recipe import and export functionality makes the applications quite sticky. The mealmaster format and JSON are the two most widespread formats. RecipeML is another alternative. |
Sqlalchemy 1.4 is not packaged with the next Debian 13 release. |
Our tests already show a similar behavior. For now,
|
Why to not put sqlalchemy 1.x in a vendor directory as php or Node.js do ? https://stackoverflow.com/questions/18812614/embedding-a-python-library-in-my-own-package |
It will not get updates. It is a well documented and well maintained project, maintenance cost should be low after update. |
Additionally, it contains native code. This means that we would have to ship the third-party wheel for every combination of OS, architecture and Python minor version. Requesting the user to compile the code manually is not suitable. For now, everyone should be able to install Gourmand from Git where we pin SQLAlchemy accordingly - at least with Python < 3.13. |
No, python3-sqlalchemy in Debian is architecture all and doesn't contains native code.
But sqlalchemy <= 2 isn't available in distribution based on Debian... |
I cannot speak for Debian, but the official wheel distribution of SQLAlchemy on PyPI has native components, although they might just be used for speeding up code. Personally, I still do not think Gourmand should ship this dependency itself as there are working solutions. Additionally, distributing the code ourselves might lead to further obligations. Downstream packagers can still employ their own methods to solve this issue - there regularly are patches which are irrelevant for upstream. If really required, bundling SQLAlchemy there would still be possible if it is relevant. Alternatively, everyone is still invited to have a look at the code and perform the actual migration. |
Upgrading to SQLAlchemy 2.x is a pain, so I'm really sorry to read another bad story about it... :( Though, please don't make this a debate about downstream distributions. The issue is in Gourmand that should be accepting the latest version of its dependencies, here SQLAlchemy. If Gourmand isn't fixed, sooner or later, it is going to be declared unmaintained, and will be gone. It is very unfortunate, but that's how it works, and this isn't specific to Debian or SQLAlchemy: dependency management is a pain, for any given software. Hopefully, someone will contribute fixes to Gourmand, and everyone will be happy ! |
As reported here 'Debian unstable)
https://bugs.debian.org/1074472
The text was updated successfully, but these errors were encountered: