search

waebbl / waebbl-gentoo

Personal overlay of gentoo ebuilds, loosely focused on the 3D domain.
17 stars 17 forks source link

PySide2: Let's Do This for the Good of FreeCAD #176

Closed leycec closed 2 years ago

leycec commented 4 years ago

Howdie, @waebbl. Pardon the momentary intrusion from a fellow overlay maintainer, but I couldn't help noticing the steaming dumpster fire in progress over here. You appear to be up PySide2 shit creek without a paddle (e.g., #169, #172, #173, #174). As the unofficial maintainer for PySide2 on Gentoo, this deeply saddens me... but it doesn't surprise me.

PySide2 is a fragile beast at best. The ebuilds you've copied here are painfully obsolete – through no fault of your own, of course. Heck, my users can't even build the PySide2 5.12.5 ebuilds I just got working. Naturally, PySide2 5.11.x ebuilds wouldn't stand a chance on a modern system.

Luckily for all, I'm almost done bumping PySide2 at my overlay to the recently released PySide2 5.14.0. This might be the perfect time for us both to... brainstorm! :cloud_with_lightning_and_rain:

wut can we possibly do

Ideally, it'd be great if we could avoid this sort of DRY going forward. There are more than a few sensible ways to do that. Fortunately, you've already implemented the best possible solution: adding my overlay as a mandatory dependency of this overlay.

This means that you're awesome! So we're almost there. All that remains to be done now is:

  1. Remove dev-python/shiboken, dev-python/pyside, and dev-python/pyside-tools. Sadly, they're all badly broken and pretty much beyond repair at this point.
  2. Bump media-gfx/freecade/freecad-0.18.3.ebuild to freecad-0.18.3-r1.ebuild.
  3. In that ebuild:
    # Replace the following two non-working dependencies... 
    dev-python/pyside:2[gui,svg,${PYTHON_USEDEP}]
    dev-python/shiboken:2[${PYTHON_USEDEP}]

    # ...with this hopefully working dependency! Specifically, note:
    # * The lack of a colon-delimited slot.
    # * The lack of an explicit "dev-python/shiboken2" dependency. Since
    #   PySide2 already requires shiboken2, requiring "dev-python/pyside2"
    #   here suffices to implicitly install shiboken2 as well.
    dev-python/pyside2[gui,svg,${PYTHON_USEDEP}]

wut? is dat really it

That's it! So, basically just a one-line change and FreeCAD should be good to go with respect to PySide2 from here on out. If you or any of your brave users hit a PySide2 issue, don't hesitate to drop me a friendly line at the raiagent issue tracker.

Thanks for all the excellent volunteerism, @waebbl. With any luck, we'll get both PySide2 and FreeCAD back into Portage before 2030. The Road to Worky is long and arduous, but we'll boldly walk it together.

waebbl commented 4 years ago

Heyo @leycec, I'm glad we're going to handle this together.

PySide2 is a fragile beast at best. The ebuilds you've copied here are painfully obsolete – through no fault of your own, of course. Heck, my users can't even build the PySide2 5.12.5 ebuilds I just got working. Naturally, PySide2 5.11.x ebuilds wouldn't stand a chance on a modern system.

Yes they are. I've copied them over from the ::qt overlay, more than a year ago and after an update to 5.11.1 I just maintained them, but never updated them again. Reason for this, was your approach to get your ebuilds into ::qt, and it saddens me, that you weren't successful with this.

Ideally, it'd be great if we could avoid this sort of DRY going forward. There are more than a few sensible ways to do that. Fortunately, you've already implemented the best possible solution: adding my overlay as a mandatory dependency of this overlay.

Although I think, this is the easiest (from a dev's POV) and technically most elegant solution, I sadly don't agree that it's the best solution from a user's point of view. I already have issues with FreeCAD users, who got irritated by this and are unsure how to handle the emerge warnings about your overlay, because they haven't enabled it. Most of them aren't devs, they are engineers, students, usually people who often don't have a deeper understanding of developing / distributing software.

So the best solution IMO would be, if we can get your ebuilds, which are superior to my Qt for Python ebuilds (not just, they're more up-to-date, but also from their python-style ebuild quality), back into the main tree. I already informed Miroslav (@fordfrog) in https://bugs.gentoo.org/622726#c98 about your overlay. He is willing to help bringing freecad and it's dependencies back into the tree.

  1. Remove dev-python/shiboken, dev-python/pyside, and dev-python/pyside-tools. Sadly, they're all badly broken and pretty much beyond repair at this point.
  2. Bump media-gfx/freecade/freecad-0.18.3.ebuild to freecad-0.18.3-r1.ebuild.

The freecad live ebuild already depends on your ebuilds optional to the ones from my overlay. I didn't do this for 0.18.3, because I'm working to bump to 0.18.4, which will depend on the Qt for Python ebuilds from your overlay.

leycec commented 4 years ago

Reason for this, was your approach to get your ebuilds into ::qt, and it saddens me, that you weren't successful with this.

Right there with you. The whole debacle was discouraging, depressing, and demoralizing.

I've mostly given up on the Qt overlay. The maintainers at that overlay have been surprisingly hostile to PySide2 – which doesn't make much sense, really. PySide2 is an official Qt-funded project. The Qt overlay should have been the perfect hosting platform for PySide2 ebuilds, but... apparently not.

I sadly don't agree that it's the best solution from a user's point of view.

Right. I sadly agree with this assessment. To simplify end-user life, we might also consider:

So the best solution IMO would be, if we can get your ebuilds, which are superior to my Qt for Python ebuilds (not just, they're more up-to-date, but also from their python-style ebuild quality), back into the main tree. I already informed Miroslav (@fordfrog) in https://bugs.gentoo.org/622726#c98 about your overlay. He is willing to help bringing freecad and it's dependencies back into the tree.

Yay! That would be phenomenal, of course. I definitely agree that this is the optimal approach.

Internal Gentoo politics are a strange and horrifying thing, though. Let's see how far Miroslav gets with this bold idea. Assuming everything goes through, I'd be happy to proxy-maintain PySide2 ebuilds from within the Portage tree... I think.

I didn't do this for 0.18.3, because I'm working to bump to 0.18.4, which will depend on the Qt for Python ebuilds from your overlay.

Oh, no worries. Sounds good! Everybody's on the same volunteer page; that's always nice. Again, just lemme know at the ::raiagent issue tracker if you or any of your users hit PySide2 issues. Thanks a bunch, @waebbl.

Perlovka commented 4 years ago

Let's kill Pesa 😈 All of this because of him.

redchillipadi commented 4 years ago

I am also keen to get pyslide or pyslide2 into the main tree, as it is needed by USD for the view applications.

leycec commented 4 years ago

Fascinating! When I read "USD," I think "U.S. Dollar" as a Canadian. But... nope. That well-known acronym really means Pixar's PySide2-based Universal Scene Description (USD) now, which I never knew even existed. I can certainly see why that would be a big deal.

Although I continue to happily maintain PySide2 at my overlay, I think we all agree that PySide2 really needs to maintained by official Portage developers from the Portage tree instead. I can't make this happen, so... let's pray for a summer miracle.

waebbl commented 2 years ago

Closing. PySide has been in the tree for a long time already.