search

AnacondaRecipes / pyqtgraph-feedstock

A conda-smithy repository for pyqtgraph.
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

Consider not depending on pyqt #1

Open hmaarrfk opened 3 years ago

hmaarrfk commented 3 years ago

The conda-forge package removed the dependency on pyqt to allow downstream users to choose pyside2 instead of pyqt.

A user has brought up the fact that this doesn't line up with what is happening in the default recipes.

It might be good for the two packages to align, but I guess thereare differences in the downstream details.

I just wanted to bring this up.

I think it is best to delay the dependency on pyqt.

Let me know what you think

https://github.com/conda-forge/pyqtgraph-feedstock/pull/15#issuecomment-712820396

hmaarrfk commented 3 years ago

cc: @bilderbuchi

mingwandroid commented 3 years ago

I think it is best to delay the dependency on pyqt

By delay you mean do not declare? If this lib depends on pyqt, as built, then that should be declared. If we build a variant that depends on pyside2 then great, we can think about how to handle that. But this is built against pyqt AFAIK and therefore needs to depend on it.

bilderbuchi commented 3 years ago

we can think about how to handle that

the thing is, pyqtgraph depends on either pyqt or pyside (the user could use either), but not none of them (so run_constrained is not sufficient). From what I could see there is currently no way to declare such a dependency relationship: a or b, a xor b, with a default if no user preference is given or set by other constraints. Is that correct? Would such a feature be desirable for conda?

mingwandroid commented 3 years ago

You'd use a variant package and build strings, probably. Similar to how blas is handled. Pinging @isuruf for recommendations here.

isuruf commented 3 years ago

Yes a mutex package named pyside_or_pyqt with two variants will be the best solution.

hmaarrfk commented 3 years ago

Yes a mutex package named pyside_or_pyqt with two variants will be the best solution.

I like that this would centralize the complexity, and not force every downstream package to have two builds.