Closed melund closed 7 months ago
Hi! This is the friendly automated conda-forge-linting service.
I wanted to let you know that I linted all conda-recipes in your PR (recipe
) and found some lint.
Here's what I've got...
For recipe:
noarch
packages can't have selectors. If the selectors are necessary, please remove noarch: python
.Hi! This is the friendly automated conda-forge-linting service.
I wanted to let you know that I linted all conda-recipes in your PR (recipe
) and found some lint.
Here's what I've got...
For recipe:
Hi!
Thanks for this pull request.
This bug was actually supposed to be already fixed by adding glib to the list of dependencies: https://github.com/conda-forge/weasyprint-feedstock/issues/23. So this workaround doesn’t work.
Weasyprint documentation states that GTK+ is required on Windows
GTK+ is not required on Windows, it’s just the easiest way to get Pango and its dependencies (including glib) installed when you don’t use a package manager like Conda.
Instead of using another workaround, I’d prefer to get the original problem solved: https://github.com/conda-forge/glib-feedstock/issues/104. Otherwise, the most reliable fix for now seems to be reinstalling glib manually after installing WeasyPrint.
Hi! This is the friendly automated conda-forge-linting service.
I wanted to let you know that I linted all conda-recipes in your PR (recipe
) and found some lint.
Here's what I've got...
For recipe:
Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe
) and found it was in an excellent condition.
Otherwise, the most reliable fix for now seems to be reinstalling glib manually after installing WeasyPrint.
That is no solution for me. A manual installation will not work in an automated workflow where we expect conda to create a working environment. I don't think it is unreasonable to add GTK as a dependency, given that is what the official documentation ask users to install.
But I don't mind adding the low level dependencies directly to the recipe instead of GTK+, if that can solve it. @liZe Do you want me to try that?
That is no solution for me. A manual installation will not work in an automated workflow where we expect conda to create a working environment.
I mean that you can call conda install glib
after calling conda install weasyprint
, as proposed in #23.
I don't think it is unreasonable to add GTK as a dependency
The problem is not to add GTK as a dependency (even if it’s ugly indeed :smile:.) The problem is that glib
had been previously added to the list to "solve" the exact same bug. And that was even just "temporary", according to the comment! So, adding GTK may work for you today, but it may not work tomorrow, or may not work for other users, for some reason I’d like to understand.
I don’t like to refuse pull requests at all 😢, but I won’t add more and more dependencies just because they sometimes solve the bug as a side effect. If it works for you, nothing prevents you from adding and maintaining this hack in your stack by installing GTK when installing WeasyPrint. Let’s hope it won’t break for you in the future, but if it does I won’t be the one to blame!
given that is what the official documentation ask users to install.
As I wrote this official documentation, I can tell you for sure that there’s no reason to install GTK when using WeasyPrint with Conda :smile:. GTK is not a dependency of WeasyPrint, it’s just an easy way to install these WeasyPrint’s dependencies on Windows when you don’t use a package manager such as Conda.
As far as I can tell, the bug is actually https://github.com/conda-forge/glib-feedstock/issues/104, and fixing it is the only reliable way to fix the problem with WeasyPrint’s package.
As I wrote this official documentation, I can tell you for sure that there’s no reason to install GTK when using WeasyPrint with Conda.
@liZe, Good point, 😆 I can also confirm that reinstalling glib conda install --force-reinstall glib
after environment creation fixes the problem.
But it got me thinking that maybe the problem is not the glib
package, but some other packages which messes up the DLL's after installation. Or maybe the order packages are linked into the environment.
I was using weasyprint through some sphinx plugin (sphinx-simplepdf
) for which there wasn't any conda-packages. So I installed all dependencies with conda, and then finally did a pip install sphinx-simplepdf´. That part only worked if I conda installed
weasyprintand then a
glib` reinstall.
(edit: Direct install of sphinx-simplepdf
did not work either, unless I manually installed gtk)
But yesterday I got a conda-forge package for sphinx-simplepdf
merged. That fixed it for me. Now I can simple do conda install -c conda-forge sphinx-simplepdf
, which gives me a working environment. Very confusing.
I can also confirm that reinstalling glib
conda install --force-reinstall glib
after environment creation fixes the problem.
That’s so strange…
But it got me thinking that maybe the problem is not the
glib
package, but some other packages which messes up the DLL's after installation. Or maybe the order packages are linked into the environment.
I don’t know. Let’s try to talk about this with the people who know what’s going on :smile:, I’ve added a comment on https://github.com/conda-forge/glib-feedstock/issues/104.
Checklist
0
(if the version changed)conda-smithy
(Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)Weasyprint documentation states that GTK+ is required on Windows. This PR adds gtk3 as dependency on Windows.
This fixes the
OSError: cannot load library 'gobject-2.0-0'"
(link) error I get when using the current package.