Add gtk2

[jakirkham]

Fixes #3914
Requires conda-forge/atk-feedstock#1 Done.

Attempts to build GTK 2 from source on Linux and macOS. Feedback and other maintainers welcome.

[conda-forge-linter]

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 (recipes/gtk) and found it was in an excellent condition.

[jakirkham]

Testing this is going to be a bit complex. Suggestions welcome.

[jakirkham]

Getting macOS support will require Cairo having X11 libraries. Please see issue ( conda-forge/cairo-feedstock#22 ) and PR ( conda-forge/cairo-feedstock#23 ) for more details.

[jakirkham]

This is blocked by PR ( conda-forge/atk-feedstock#1 ) ATM. Once that is merged and packages released, we can revisit this.

[jakirkham]

cc @ocefpaf @pkgw @sdvillal @Korijn

[jakirkham]

Built atk and gtk for Linux and have placed them in my channel, jakirkham, if anyone would like to test them.

[jakirkham]

cc @ccordoba12

[sdvillal]

I agree that testing can be a bit tricky. I have installed your packages, look at how DSOs get resolved and it all looks good to me. Perhaps what we should do is to build and run something against this to exercise it a bit.

Here is our old recipe if it can be of help.

[ccordoba12]

Thanks for this @jakirkham! Unfortunately, I can offer a hand here because I've never compiled Gtk.

[jakirkham]

Borrowed some common flags used to build GTK from various sources (mainly Homebrew and Linuxbrew though MacPorts and the loopbio recipe were looked at as well). Have enabled the macOS build using Quartz (not X11), which is consistent with these sources and seems to build ok. Also made some minor tweaks to the tests at the end.

[jakirkham]

Have uploaded new packages to my own channel, jakirkham, for gtk. Overwrote the old packages in the process for simplicity.

[jakirkham]

Not sure how we want to pin this.

[jakirkham]

Not sure how we want to pin these.

[jakirkham]

Not sure how we want to pin these.

[jakirkham]

Not sure how we want to pin these, if at all.

[jakirkham]

Not sure how we want to pin this.

[jakirkham]

Anyone else want to help maintain? I'm afraid I can't promise lots of time to this myself.

[pkgw]

I can help.

[pkgw]

Can we call this package "gtk2"? Gtk+3 has been around for a looooong time at this point and should be considered the "normal" Gtk. They are parallel-installable and it should be possible for users to have both versions 2 and 3 installed at the same time.

[jakirkham]

So this is an interesting question. We have not tended to have SO named packages (with some exceptions like pcre and pcre2). For instance, qt is not an SO named package. My initial thought was to do the same with gtk. This would make it easier if people want to select GTK 2 based packages versus GTK 3. Though it does seem like Linux distros, Homebrew, and MacPorts do use the SO name with GTK. So this would be pretty consistent with what other packagers have done. All of this being said, I have no real strong feelings on it. Though would like to see some buy-in for how we name it. Perhaps @conda-forge/core and @conda-forge/staged-recipes could weigh in.

[pkgw]

That's a choice to be made by the packager, not the user, no? If I'm packaging the foo application I can choose which one it will depend on. I don’t see there being much reason to try to provide both alternatives to users.

[jakirkham]

That's a choice to be made by the packager, not the user, no?

Sure. I overloaded user here. Meant a packager downstream of gtk. 😄

If I'm packaging the foo application I can choose which one it will depend on. I don’t see there being much reason to try to provide both alternatives to users.

Yes, you can totally choose. Though the question is what if you want to support both gtk 2 and 3? How should this downstream packager handle such a case? Just want to make sure there is a standard framework for downstream packagers to handle such a problem.

[pkgw]

@jakirkham Based on a lot of experience with Gtk software packages over many years, I will assert that downstream packages virtually never have simultaneous support for Gtk2 and Gtk3; they either have one or the other. I am pretty sure that I've literally never seen this. That might be a bit less true for programs based on PyGtk since it's easier to be loosey-goosey with Python code than C, but even in that case, the recommended Python APIs changed substantially so one generally needed to make a firm choice. (Personal experience here).

So basically I don't think issue of downstream packages that want to support either 2 or 3 is one that will arise in practice.

[jakirkham]

OpenCV can support Gtk2 or Gtk3.

[jakirkham]

cc @patricksnape

[sdvillal]

The goal being to have a consistent software stack, shouldn't the rule simply be like this?

• if two packages can be installed together, let them be installed together
• if two packages should not be installed together, do not let them be installed together

Now, in the very simplified conda packaging world, where there are very few ways to express relationships between packages, we can read "let two packages be installed together" as "let two packages be named differently".

I think there should be no discussion about this. Installing gtk2 and gtk3 on the same environment should be possible. Therefore both packages should be named differently.

There is then no trouble downstream. For example, in the rare case we would want to have support for all three gtk2, gtk3 and qt4 as opencv highgui backends, we would then just have three versions of the opencv package bringing along their corresponding dependencies. The concrete version would be selected with the build string, or via a conda feature if you want. The user will install whatever version she needs. And that would not mean other opencv-unrelated packages depending on other gui toolkits to be affected.

The gtk2 + gtk3 should be allowed to be installed in the same environment is in clear contrast with other packages that should not be allowed to end up in the same environment but still are not named the same (thinking on the cpu vs gpu versions of some packages in defaults that can be happily and wrongly installed side by side).

[pkgw]

@jakirkham I stand corrected.

[jakirkham]

I'm sure you are right that this is hardly the norm. OpenCV is really a behemoth.

[jakirkham]

cc @oinizan

[jakirkham]

Going to try to bring this back to life.

I think there should be no discussion about this. Installing gtk2 and gtk3 on the same environment should be possible. Therefore both packages should be named differently.

I don't think we are discussing this point any more. We are in agreement.

There is then no trouble downstream. For example, in the rare case we would want to have support for all three gtk2, gtk3 and qt4 as opencv highgui backends, we would then just have three versions of the opencv package bringing along their corresponding dependencies. The concrete version would be selected with the build string, or via a conda feature if you want.

This is where we are having a disagreement I think. There is a challenge for downstream packagers to specify this in a consistent manner as there currently isn't one solution. 😄 So what I'm asking is for us to settle on one of these solutions. For BLAS selection, we have the blas package (feature-based), which could be an option here. Some have used build string style selection with the LLVM toolchain to some success. The feature solution is good if we want to force one GUI backend for all things. The build string solution is good if we want to allow different packages to use different GUI backends. Personally I don't have strong opinions as far as this goes with GUI backends (maybe build string?), but I do think it is important for us to agree on the solution and document it. Otherwise different packages may adopt different solutions, which would be a nightmare for end users. Picking a solution for the community to follow avoids that. Does this sound reasonable? Any other thoughts? 😉

[scopatz]

I personally find using features a little annoying to develop with. If the string method works, I would be in favor of that.

[sdvillal]

I agree with @scopatz. I think that the only proper solution we currently have is to recommend the build string method. Hypothetical downstream dependents that provide two variants, one for gtk2 and one for gtk3, would be selected like downstream=3.3=*gtk2*.

To my mind, conda features are not only annoying to use. They simply do not cut it here. Because gtk2 and gtk3 can be installed side by side, each of them need to track a different feature. This is true even with new conda 4.4 key-value features: the feature cannot be "gtk=[2|3]" (which would allow only one of the two gtk variants in the environment) but instead "gtk2=present" and "gtk3=present". If the two downstream package variants only differ on requiring one of the two different features, how will the downstream package be resolved when both features are provided by the environment? I think randomly in conda < 4.4. In conda >= 4.4, if I understand correctly, we could maybe use the [features="gtk2=present"] syntax, which seems clumsy.

To allow the user to choose one version or the other via conda features, we would also add a "downstream-gtk2-feature" and "downstream-gtk3-feature" per downstream package. I think that is painful too, both for the packager and the user.

Having different downstream package names should also be discarded - for the obvious reason they won't be anymore variants of the same package but two different packages that could wrongly be installed on parallel and that would force further differentiation/split of dependents.

[sdvillal]

Just a side note: I think the "blas package tracking feature" is an unfortunate historical event. For example, openblas and MKL can, at the moment, both be installed on parallel. So this discussion could apply also to them.

[jakirkham]

Could you please weigh in on this one if you have time, @mingwandroid? It would be very helpful to hear your thoughts on this. In particular how we solve the Gtk2/Gtk3 issue going forward.

[mingwandroid]

I would ignore gtk2 here. We should be thinking about gtk4 now-a-days. I know I'm sidestepping the core issue, but I think we can reasonably consider gtk2 as useful as Qt4 and there's no way on earth I'd consider spending a minute's effort on Qt4 (yeah we already have it, but that's due to historical efforts).

Anyway, if it is true that:

gtk2 and gtk3 can be installed side by side

.. then I don't agree with with:

each of them need to track a different feature

.. and I also do not agree with:

Having different downstream package names should also be discarded - for the obvious reason they won't be anymore variants of the same package but two different packages that could wrongly be installed on parallel and that would force further differentiation/split of dependents

Because I do not see it as painful at all for anyone. Legacy software that doesn't work with gtk3 (or 4!) would be built against gtk2 (or 3!) and everything else would be built against gtk3 (or 4!) and they can both be installed in the same environment and I think that's completely fine personally.

[mingwandroid]

.. overall, the point I am making here is that there's no intrinsic 'value' in ever using gtk2 when you have the option to use gtk3. There are no benefits conferred to the end user and they will never say "but I want the gtk2 variant" the same as they'll never say "I want Qt4 instead of Qt5".

[jakirkham]

As we do package legacy software in other cases where we need it, this doesn't seem that unusual. Given we are often using gtk2 from yum, having this as a conda package would get us away from using yum to install it, which is already an improvement IMHO. Given this, are there any blockers to merging?

[jakirkham]

cc @conda-forge/staged-recipes

[scopatz]

I think we should take the plunge and fix things in the feedstock, as needed.